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ABSTRACT 

Information  systems  are  an  integral  part  of  the  United  States  Navy.  The 
effectiveness  of  the  Navy's  administrative,  logistic  information  systems  is  dependent  on 
the  Navy's  ability  to  acquire,  develop  and  maintain  them. 

This  thesis  will  review  current  acquisition  stategy  guidelines,  policies  and  the 
resulting  acquisition  strategy  plans  for  major  Navy  administrative  logistic  information 
systems.  An  attempt  will  be  made  to  determine  changes  which  can  be  made  to  improve 
the  system  and  enable  the  Navy  to  keep  pace  with  technology  advances. 
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I.  INTRODUCTION 

A.       DISCUSSION 

The  Federal  government  is  facing  a  phenomenal  growth  in  the  use  of  automated 
systems.  This  growth  has  resulted  in  an  increasing  reliance  on  data  processing  and 
telecommunications  technology  to  support  government  programs  [Ref  1:  p.  1].  Not 
surprisingly,  this  growth  has  resulted  in  the  use  of  automated  systems  in  the  Federal 
government  expanding  to  such  a  degree  that  the  Federal  government  is  totally 
dependent  on  these  automated  systems  [Ref  2:  p.  v]. 

The  fact  that  this  growth  of  automated  systems  has  all  occurred  within  the  last 
three  decades  [Ref  3:  p.  16]  compounds  the  pressures  faced  by  all  branches  of  the 
Federal  government.  The  Department  of  the  NavT  (DON),  as  one  branch  of  the 
Federal  government,  must  develop  and  maintain  both  it's  hardware  and  it's  software 
under  ever  expanding  demands  for  their  use.  Indeed,  the  total  demand  for  software 
within  the  Department  of  Defense  (DOD)  is  anticipated  to  increase  at  a  rate  of  twelve 
percent  per  year  for  the  next  two  decades  [Ref  4:  p.  30]. 

While  the  growth  in  scope  and  complexity  of  these  automated  systems  has  been 
phenomenal,  the  management  problems/challenges  this  growth  has  engendered  are  not 
unique.  Private  industry  has.  and  is  facing  similar  growth  issues  [Ref  5:  p.  IJ.  The 
problems  of  incompatible  data,  functionally  obsolescent  hardware  and  inefTicient 
software  are  only  some  of  the  factors  compounding  the  Nave's  IS  growth  issues 
[Ref  6:  p.  VI 1 1-55].  The  shortfall  in  software  professionals,  available  to  meet  the 
increasing  demands  of  private  industry  and  the  Federal  government,  is  predicted  to 
reach  one  million  by  1990  [Ref  4:  p.  30]. 

For  the  Na\7,  these  problems  are  compounded  by  it's  own  regulations  [Ref  6:  p. 
VI 1 1-86].  Regulations  which  often  result  in  increased  complexity  and  frustration  for 
government  IS  managers  [Ref  7:  pp.  12-13].  Criticisms  of  the  DOD  acquisition 
process  "have  focused  on  the  acquisition's  taking  too  long,  costing  too  much,  and 
resulting  in  operational  systems  that  do  not  perform  as  expected  [Ref  8:  p.  l-l].  How 
the  Na\7  tackles  these  problems  and  the  problems  of  aging  hardware  [Ref  9:  pp.  5-S] 
and  obsolescent  software  [Ref  10:  pp.  55-56]  will  determine  how  efficient  the  Na\7  is 
in  the  future. 


The  way  automated  systems  and  computers  are  viewed  is  changing  just  as  rapidly 
as  the  number  of  computers  and  systems.  The  distinction  between  automated  data 
processing  (ADP),  word  processing  (WP),  and  data  communications  are  increasingly 
being  blurred  [Ref.  5:  p.  28].  The  change  of  emphasis,  within  DOD.  from  automated 
data  systems  (ADS),  to  automated  information  systems  (AIS).  to  information  systems 
(IS)  is  indicative  of  this  change. 

IS  is  the  term  now  bemg  used,  by  the  Xa\w,  to  identify  automated  computer 
systems.  IS.  with  it's  focus  on  the  end  product  (information),  is  changing  the  way  the 
Na\y  views  system  acquisition.  Acquisition  Strategy,  as  a  portion  of  the  total  Life 
Cycle  Management  (LCM)  effort,  must  (by  necessity)  adapt  to  this  focus  on  the  end 
product  (information). 

B.       SCOPE  OF  THESIS 

The  scope  of  this  thesis  is  limited  to  an  analysis  of  major  Navy 
administrative  logistics  information  system  acquisition  plans. 

The  definition  of  a  major  system  is  a  system  which  exceeds  eight  million  dollars 
in  life  cycle  cost  over  a  five  year  period  [Ref  11:  p.  i].  This  definition  will  be  dealt  with 
in  more  detail  in  Chapter  III. 

An  administrative  logistic  system  is  defined  as  a  system  which  deals  primarily 
with  administrative  logistic  functions  (e.g.  payroll,  finance,  personnel  management. 
inventor.'  control  and  supply).  From  a  hardware  perspective  ,  administrative  logistic 
systems  are  associated  with  "...  general  purpose,  commercially  available,  mass 
produced  automatic  data  processing  components  and  the  equipment  systems  created 
fiom  them  ..."  [Ref  12:  p.  2]. 

SECNAVINST  523  LIB  uses  this  classification-by-function  for  all  IS's 
[Ref  14:  pp.  2-4].  Functional  class  "A"  roughly  equates  with  the  administrative  logistic 
systems  this  thesis  deals  with. 

The  reasons  for  dealing  with  only  administrative  logistic  systems  is:  (1)  to  narrow 
the  scope  of  research  and,  (2)  to  isolate  those  systems  which  are  most  closely  aligned 
with  systems  found  in  private  industrv'.  The  belief  is  that  current  acquisition  strategies 
do  not  provide  the  flexibility  that  private  industn."  utilizes,  and  that  consequently  Navy 
acquisition  strategies  are  not  as  efTective  as  those  possible  in  private  industrv".  The 
challenge  is  to  identify  those  aspects  of  Navy  acquisition  strategy  which  add  to 
flexibility  and  to  emphasize  their  use. 


The  tactical  systems  orientation  of  functional  classes  "B"  and  "C"  (refer  to 
SECNAVINST  5231. IB)  introduces  a  bias  in  comparison  with  private  industry  which  is 
much  more  complex  to  isolate.  Additionally,  the  waivers  and  exceptions  which  are 
encountered  in  dealing  with  tactical  systems  (e.g.  the  Warner  Amendment)  make 
acquisition  strategies  in  this  realm  more  flexible,  and  therefore  not  as  significant  an 
impediment  to  effective  systems  acquisition  as  the  narrower  guidance  allowable  for 
non-tactical  systems. 

The  result  of  this  dichotomy  between  tactical  and  non-tactical  is  that  while  most 
administrative  logistic  systems  are  non-tactical  in  nature,  a  number  of 
administrative;  logistic  systems  are  classified  as  tactical  systems.  Although  only  a 
hypothesis,  it  can  be  conjectured  that  some  administrative/logistic  systems  are  classified 
as  tactical  systems  in  order  to  obtain  the  benefits  associated  with  the  more  flexible 
tactical  environment. 

C.       METHODOLOGY 

The  metodology  utilized  in  this  thesis  is  fourfold  and  cumulative  in  nature.  First, 
a  review  of  current  directives,  instructions  and  guidance  on  the  acquisition  of  major 
automated  systems  was  conducted.  Second,  interviews  with  various  program  managers 
and  contracting  officers  were  conducted.  Third,  a  review  of  current  major  system 
acquisition  plans  was  conducted.  Fourth,  using  the  results  of  steps  one  through  three, 
an  analysis  of  current  acquisition  plans  was  conducted  in  an  effort  to  identify  areas  for 
potential  improvement  in  the  acquisition  strategy  process. 

During  the  interview  phase,  two  general  questions  were  posed: 

(1)  What  instructions  directives  references  are  pertinent  to  the  development  of  a 
major  system  acquisition  strategy  plan 

(2)  What  problems,  if  anv.  are  faced  by  personnel  developing  major  information 
system  acquisition  strategy  plans 

Additionally,  individuals  were  asked  to  forward  a  copy  of  any  major  systems 
acquisitions  they  were  currently  working  on. 

At  the  beginning  of  the  discussion  interview,  which  was  not  structured  beyond 
raising  the  questions  identified  above,  it  was  necessary  to  define  an  acquisition  strategy 
plan.  For  this  phase  an  acquisition  strategy  plan  was  broadly  defined  to  be  that  plan 
being  used  by  the  P.VI  to  guide  his  acquisition  (regardless  of  the  referential  basis  for  the 
acquisition  strategy  plan). 
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Interviews  revealed  general  agreement  on  which  references  were  pertinent,  but 
surprisingly  many  individuals  were  not  in  possession  of  the  most  recent  versions  of  the 
references  they  cited.  Problems  identified  during  the  interviews  were  generally  minor 
and  centered  on  operational  questions. 

Some  ideas  for  improvement  were  provided  and  ranged  from  better  enforcement 
to  scrapping  of  guidelines.  These  ideas  were  considered  and  certainly  influenced  the 
proposed  changes  developed  in  Chapter  V. 

While  primarily  Na\T  oriented,  research  included  personnel,  directives  and 
acquisition  strategy  plans  from  the  Defense  Logistics  Agency  (DLA).  the  Air  Force, 
the  Army  and  private  industr\'.  This  external  review  was  not  exhaustive  and  was 
conducted  for  purposes  of  comparison  and  potential  solution  generation. 

A  list  of  acronyms  and  abbreviations  is  provided  in  Appendix  A. 
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II.  ACQUISITION  PLANNING 

A.       INTRODUCTION 

Acquisition  planning  is  the  process  of  integrating  and  documenting  the  efTorts 
needed  to  acquire  material  resources  for  a  program  into  a  comprehensive  acquisition 
strategy  plan.  The  principal  objective  of  acquisition  planning  should  be  the  statement 
of  acquisition  and  contracting  objectives.  This  objective  must  convey  concisely  and 
clearly  the  user's  needs,  uncluttered  by  the  technical  details  of  contractual  "legalize". 

The  program  manager  (P.VI)  is  responsible  for  the  development  of  the  acquisition 
strategy  plan.  He'she  accomplishes  this  development  through  the  acquisition  planning 
process.  Williams  and  Knittle  identified  the  basic  acquisition  strategy  planning  process 
used  in  DOD  in  19S1  [Ref  16:  p.  9].  The  process  they  identified  is  essentially  the  same 
today.   The  basic  acquisition  planning  process  is  depicted  in  Figure  2.1. 

While  superficially  straightforward,  few  individuals  understand  the  nuances  of 
acquisition  planning.  The  list  of  these  nuances  and  details  involved  in  acquisition 
planning  results  because  of  the  varying  references  and  interpretations  concerning  the 
acquisition  planning  process.  These  nuances,  in  part,  have  resulted  in  the 
misunderstandings  and  conflicts  identified  in  the  public  literature. 

The  Chief  of  Naval  Operations  (CNO)  recognized  the  misunderstanding 
surrounding  the  development  of  an  acquisition  strategy  and  issued  a  memorandum  to 
clarify  what  an  acquisition  strategy  is  [Ref  17:  p.  1].  Specifically,  the  CXO  stated  that 
"the  purpose  of  the  acquisition  strategy  is  to  provide  a  succinct  summar\'  of  what  is,  or 
what  IS  intended  to  be,  in  the  acquisition  plan"  [Ref  17:  p.  I]. 

While  not  illuminative,  this  clarification  does  minimize  the  scope  of  an 
acquisition  strategy  to  a  specific  document  recognized  by  PM's  within  DOD.  The 
system  acquisition  strategy  plan  is  referred  to  in  numerous  documents  and  this  chapter 
is  intended  to  (1)  discuss  the  framework,  encompassing  acquisition  strategy 
development,  (2)  outline  the  references  pertinent  to  acquisition  strategies,  (3)  highlight 
the  contractual  procurement  aspects  of  an  acquisition  strategy,  and  (4)  discuss  the 
scope  and  limitations  of  current  acquisition  strategy  concepts. 


B.       FRAMEWORK 

In  order  lo  understand  how  acquisition  strategy  is  developed,  it  is  necessar\'  to 
understand  the  context  within  which  the  acquisition  planning  process  takes  place. 

Acquisition  planning  begins  with  the  documentation  of  a  program  need.  Thus, 
an  acquisition  strategy  plan  is  prepared  concurrently  with  a  program's  inclusion  in  the 
Program  Objective  Memorandum  (POM)  process,  it  may  be  helpful  to  view 
acquisition  planning  from  two  perspectives  perspectives--a  financial  perspective  and  an 
acquisition  perspective. 

These  two  perspectives  are  mirrored  by  the  two  major  processes  which 
encompass  the  information  system  acquisition  process:  (1)  the  Planning,  Programming, 
and  Budgeting  System  (PPBS),  and  (2)  the  ADP  system  acquisition  process.  These  two 
processes  are  parallel,  but  overlapping  efforts.  The  primary'  area  of  overlap  occurs  in 
the  analysis  and  approval  of  the  mission  need.  Given  an  approved  need,  the 
alternatives  to  satisfy  that  need  are  investigated.  For  example,  a  specific  mission  need 
may  best  be  satisfied  by  a  change  of  regulations,  directives,  by  redeployment  of  existing 
resources,  by  training,  or  by  a  new  major  system  acquisition.  Only  if  the  alternative 
selected  is  to  use  "acquisition"  is  the  ADP  system  acquisition  process  triggered. 

The  PPBS  process  identifies  the  need,  translates  that  need  into  resource 
requirements,  then  into  budget  proposals  and  finally  into  programs.  Inputs  to  the 
PPBS  process  are  Joint  Chiefs  oi"  StatT  (JCS)  and  .VIilitar>'  Department  planning 
documents,  Militarv'  Departments  Program  Objective  Memoranda  (POMs)  and  budget 
estimates.  Outputs  are  the  Defense  Guidance  (DG),  the  Five-Year  Defense  Plan 
(FYDP)  and  the  DOD  portion  of  the  President's  budget.  Anyone  entering  the  system 
acquisition  arena  must  have  a  working  knowledge  of  PPBS.  This  thesis  does  not 
assume  to  present  the  level  of  understanding  needed,  but  only  a  basic  overview.  The 
basic  PPBS  process  pertinent  to  system  acquisition  is  depicted  in  Figure  2.2. 

The  ADP  system  acquisition  process  begins  when  a  Mission  Element  Needs 
Statement  (MEN'S)  has  been  approved  by  the  agency  head.  This  approval  occurs  at 
Milestone  0.  At  this  point  a  program  manager  (PM)  is  normally  assigned  to  the 
system  acquisition  effort.  Alternatives  are  explored,  considered  and  the  acquisition 
strategy  for  the  desired  alternative  is  developed.  It  must  be  remembered  that  during 
this  time  the  acquisition  process  is  overlapped  with  the  PPBS  process.  The  PPBS 
process  incorporates  strategic  planning  prior  to  dealing  with  need  and  alternatives,  and 
then  places  it's  emphasis  on  financial  aspects.  The  ADP  acquisition  process  begins  with 
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the  need  and  alternatives,  and  then  passes  financial  requirements  back  and  forth  with 
the  PPBS  process. 

Upon  approval  of  the  requirements  in  the  PPBS  process,  the  PM  initiates  the 
actual  acquisition  planning  efforts  and  manages  this  effort  until  completion.    This  basic 
y        ADP  acquisition  cycle  is  also  referred  to  as  the  life  cycle  of  an  AIS.  The  basic  phases 
of  the  ADP  acquisition  cycle  are: 

(1)  Mission  Analysis  Project  Initiation 

(2)  Concept  Development 

(3)  Definition  Design 

(4)  System  Development 

(5)  Deployment  Operation  [Ref  18:  p.  2] 

This  basic  ADP  system  acquisition  process  is  graphically  depicted  in  Figure  2.3. 

The  basic  ADP  system  acquisition  cycle  is  dynamic  in  nature.  The  P.VI  is 
allowed  to  combine  milestones  phases  as  long  as  this  action  is  included  in  his 
documentation  at  Vlilestone  0  and  approved.  The  ability  of  the  PM  to  adapt  (within 
parameters)  the  ADP  acquisition  process  to  suit  his/her  particular  program  is  a 
valuable  tool  for  achieving  flexibility. 

What  must  be  remembered  is  the  overall  objective  s  the  PM  is  tr\'ing  to  achieve. 
The  total  acquisition  planning  process  seeks  to  achieve  the  following  objectives: 

(a)  Assure  manasement  accountability  for  the  success  or  failure  of  AIS 
developments  "and  identifv  the  roles  and  responsibilities  of  functional, 
telecommunications  and  ADP  managers  throughout  the  Ufe  cycle  of  an  AIS. 

(b)  Establish  a  control  mechanism  to  assure  that  an  AIS  is  developed,  evaluated 
and  operated  in  an  effective  manner  at  the  lowest  total  overall  cost. 

(c)  Provide  visibility  for  all  resource  requirements  of  an  AIS  and  communicate 
with  Congress  early  in  the  acquisition  process  for  a  major  AIS. 

(d)  Promote  cost  efTective  standardization  of  AISs  for  use  throughout  the 
Department  of  Defense  [Ref  IS:  p.  2J. 

Unfortunately,  these  objectives  may  conflict,  and  the  PM  must  recognize  the 
need  for  prioritizing  goals  based  on  a  trade-ofT  analysis.  Tradeoffs  are  often  overlooked 
as  the  PM  attempts  to  satisfy  written  instructions,  as  opposed  to  establishing  a  general 
direction  for  the  acquisition  planning  effort. 

SECDEF  establishes  acquisition  policy  to  ensure  that  major  programs  are  being 
pursued  in  response  to  identified  needs  and  using  good  management  practices.  As  part 
of  the  acquisition  process,  a  Defense  Acquisition  Board  (DAB)  was  established  to 
review  programs  and  make  recommendations  to  SECDEF  on  program 
accomplishments. 
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C.       REQUIREMENTS/INSTRUCTIONS 

The  acquisition  process  utilized  today  is  a  result  of  initiatives  of  the  1970's. 
Secretan.-  of  Defense  (SECDEF)  Packard  initiated  DOD  Directive  5U00. 1  and  the 
associated  5000  series  instructions  that  followed.  These  documents  laved  the 
foundation  for  the  acquisition  policies  of  today. 

A  review  of  the  directives,  instructions  and  guidance  pertinent  to  the  acquisition 
of  major  automated  systems  yields  an  extensive  hbrary  of  materials.  In  1979,  the 
library  pertinent  to  major  system  acquisition  included  "one  public  law,  eight  OiRce  of 
Management  and  Budget  (OMB)  circulars,  forty-four  Federal  Information  and 
Processing  Standards  (PIPS)  publications,  twenty-eight  Government  Accounting  ofilce 
(GAO)  reports  and  studies  and  a  multitude  o[  other  directives  and  regulations 
[Ref.  3:  pp.  7-8].  The  number  has  not  decreased,  rather  it  has  increased.  In  1982,  there 
were  over  114  directives  related  to  acquisition  [Ref.  19:  pp.  12-17].  Navy  instructions 
use  three  page  enclosures  merely  to  list  the  references  that  are  pertinent  to  systems 
acquisition  [Ref  14].  This  plethora  of  guidance  often  overlaps  and  routinely  causes 
outsiders  to  question  the  need  for  so  much  bureaucratic  overhead. 

Interviews  with  program  managers  and  contracting  ofTicers,  who  should  be 
conversant  with  this  material,  reveals  an  additional  problem.  Only  two-thirds  o[  the 
individuals  interviewed  had  up-to-date  copies  of  the  references  they  were  utilizing.  The 
fact  that  not  all  individuals  maintained  all  the  references  is  understandable.  The  fact 
that  they  were  not  aware  of  revisions  is  not  understandable. 

Na\w  instructions  are  generally  used  to  implement  higher  authority  directives  and 
guidance.  This  practice,  of  implementing  higher  authority  directives,  is  not  unique  to 
the  Navy,  the  other  military  services  follow  the  same  procedure.  The  use  of 
implementing  instructions  allows  the  addition  of  tailored  information  and  specificity, 
which  supposedly  makes  subordinate's  jobs  easier.  Unfortunately,  this  often  is  the 
cause  of  conflicting  guidance  because  implementing  instructions  are  not  kept  current 
with  higher  authority  directives.  While  most  personnel  involved  in  major  system 
acquisition  are  relatively  senior  and  therefore  more  conversant  with  the  necessar\- 
references,  the  ability  to  stay  abreast  of  changing  conditions  and,  or  references  does  not 
diflerentiate  by  seniority.  Personnel  involved  in  major  system  acquisition  must 
understand  both  the  source  and  intent  of  major  system  acquisition  guidance  in  order  to 
elTectively  acquire  systems  in  today's  environment. 
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To  achieve  this  understanding  of  system  acquisition  planning  it  is  necessar\-  to 
understand  the  contents  of  the  key  documents  contained  in  appendix  C.  Appendix  C 
provides  a  listing  of  the  principal  references  needed  to  understand  major  IS  acquisition 
planning.  The  following  paragraphs  provide  a  summary  of  the  contents  of  the  key 
documents  associated  with  major  IS  acquisition  planning. 

Public  Law  S9-306  (Brooks  Bill) 

The  Brooks  Bill  made  the  General  Services  Administration  (GSA)  responsible  as 
the  sole  procurement  agent  for  the  Federal  government  for  all  ADP  acquisitions.  This 
responsibility  is  delegable  and  is  recognized  as  procurement  delegation  authority  (PDA) 
within  DON.  The  National  Bureau  of  Standards  (NBS),  under  the  Department  of 
Commerce  was  made  responsible  for  Federal  ADP  standards.  These  standards  are 
known  as  Federal  Information  and  Processing  Standards  (FIPS).  The  OOice  of 
Management  and  Budget  (OMB)  was  made  responsible  for  ADP  policy  formulation 
and  for  solving  inter-agency  disputes  with  GSA. 

Public  Law  96-51 1  {Paperwork  Reduction  Act) 

The  Paperwork  Reduction  Act  requires  the  creation  of  a  senior  official  in  each 
agency  to  be  responsible  for  information  resource  management,  including  computer 
processing  resources.  The  Act  recognizes  the  convergence  of  ADP  and 
Telecommunications.  It  excludes  tactical  systems  from  the  scope  of  the  Act.  It 
establishes  the  OtTice  of  Information  and  Regulatory  Affairs  within  OMB,  to  be 
responsible  for  government-wide  information  resource  management. 

Title  10  U.S.C.  2315  {Warner  Amendmeni) 

The  Warner  Amendment  exempts  tactical  computer-based  systems  from  the 
requirements  of  the  Brooks  Bill. 

Federal  Acquisition  Regulation  {FAR),  Part  7 

The  FAR  establishes  procedures  for  developing  acquisition  plans.  Requires 
procedures  to  promote  and  provide  for  full  and  open  competition.  It  specifies  the 
content  of  written  acquisition  plans.  Provides  milestones  for  the  acquisition  cycle  and 
other  considerations  pertinent  to  the  acquisition  planning  process.  It  identifies 
guidance  pertaining  to  the  decision  to  acquire  equipment  by  lease  or  purchase. 
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DOD  FAR  Supplement,  Part  / 

The  DOD  FAR  Supplement  implements  FAR  requirements  within  DOD.  It 
establishes  dollar  thresholds  requiring  written  acquisition  plans.  It  requires  written 
acquisition  plans  to  be  keyed  to  the  Department  of  Defenses  Five  Year  Defense 
Program  (FYDP),  applicable  budget  submissions  and  the  Decision  Coordinating 
Paper  Program  Memorandum,  as  appropriate.  It  dilTerentiates  between  system 
acquisition  plans  and  acquisition  plans  {allows  for  breakouts).  It  requires  "design-to- 
cost"  considerations  (DODD  4245.3).  It  incorporates  life-cycle-cost  criteria. 

DODD  5000.1  {Major  System  Acquisitions) 

DODD  5000.1  implements  OMB  Circular  A-109  and  Public  Law  98-191.  It 
promotes  decentralization  and  delegation  to  the  maximum  extent  feasible.  It  stresses 
operational  elTectiveness  and  operational  stability.  It  establishes  milestone  decision 
points  for  acquisition  process  within  DOD.  It  sets  criteria  for  major  system  designation 
as  a  system  whose  estimated  cost  exceeds  S200  million  (RDT&E)  or  SI  billion  in 
procurement  funds,  or  both. 

DODD  5000.2  (Major  System  Acquisition  Procedures) 

DODD  5000.2  implements  DODD  5000.1.  It  estabUshes  procedures  for  the 
Defense  Acquisition  Board  (DAB).  It  discusses  the  integration  of  the  PPBS  with  the 
ADP  system  acquisition  process.  It  sets  forth  principles  that  shall  be  considered  in 
planning  any  major  system  acquisition  (see  Appendix  D). 

DODD  7920.1  {LCMofAISs) 

DODD  7920.1  estabUshes  policy  governing  the  life  cycle  management  and  control 
of  automated  information  systems.  It  defmes  major  automated  information  systems  for 
DOD.  It  sets  purpose  and  content  of  the  life  cycle  phases  for  AISs.  It  provides  the 
formal  and  concept  supporting  the  use  of  the  Mission  Element  Needs  Statement 
(MENS).  It  is  tied  to  DODD  5000.1. 

DODD  7920.2  (Major  A  IS  Approval  Process) 

DODD  7920.2  provides  the  approval  process  for  those  AISs  which  do  not  meet 
the  thresholds  of  a  major  system  provided  in  DODD  5000.1,  but  still  considered  as 
major  information  systems  within  DOD. 
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Xavy  Acquisiiion  Regulations  Supplement  [SARSUP) 

The  NARSUP  implements  the  FAR  within  the  Navy.  It  expands  the  content  of 
the  written  acquisition  plan  required  by  the  FAR.  It  differentiates  between  the 
thresholds  for  acquisition  plans  between  NAVSEA/NAVAIR  and  all  others. 

SECSAVIXST  4210.7 

SECNAVINST  4210.7  establishes  a  Na\7-wide  priority,  when  procuring 
hardware,  software,  to  use  non-developmental  items  (NDI).  It  requires  acquisition 
plans  to  describe  the  extent  to  which  NDI  is  proposed  and  to  clearly  justify  where  use 
of  NDI  is  not  feasible  or  cost  effective. 

SECX  AVIS  ST  5000.1  B 

SECNAVINST  5000. IB  implements  DODD  5000.1.  It  establishes  Acquisition 
Categories  (ACATs).  ACATs  determine  the  level  of  review  and  decision  authority 
appropriate  for  programs. 

ONASISST  5000.29A 

ONASINST  5000. 29A  promulgates  policy  for  the  development  of  acquisition 
strategy  papers.  It  requires  acquisition  strategy  documentation  within  90  days  of 
program  initiation  (POM  approval).  It  identifies  the  use  of  acquisition  strategy  papers 
as  the  basis  for  development  of  other  program  documentation,  e.g.  SCP,  NDCP,  DCP, 
TEMP. 

SECS  AViy  ST  5231.1  B 

SECNAVINST  5231. IB  provides  standards  for  managing  all  IS  projects.  It 
adapts  SECNAVINST  5000. IB  for  IS  projects.  It  incorporates  ADP,  WP,  and  data 
communications  within  the  definition  of  IS.  It  permits  IS  projects  under  SIOOK  to  be 
managed  under  a  one  stage  LCM  strategy,  using  an  ASDP.  It  establishes  the  IS 
Executive  Board  to  perform  NSARC  functions  for  IS  programs. 


D.       PROCUREMENT  IMPACTS 

The  most  documented  and  controversial  aspect  of  acqusition  planning  is  the 
aspect  of  procurement.    While  procurement  is  not  a  mandator}'  element  of  a  system 
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development,  all  major  IS  projects  currently  include  over  half  of  the  estimated  cost  as 
part  of  a  contracting  etTort.  Within  the  Na\T.  the  procurement  contracting  effort  has 
become  highly  technical  and  specialized  [Ref  21:  pp.  40-42).  The  PM.  having 
developed  the  acquisition  strategy,  interfaces  with  the  contracting  officer  (KO)  to 
develop  specific  contracting  strategies  to  support  the  acquisition  strategy  plan. 

While  "...  the  contingent  nature  of  acquisition  contract  planning  ..." 
[Ref.  16:  p.  14]  mandates  flexibility,  flexibility  is  not  the  sole  goal  of  the  KO.  The  KO 
must  satisfy  the  PM's  requirements  within  the  guidelines  of  the  law.  The  PM  needs  to 
remember  that  the  KO  has  these  two.  often  opposing,  goals.  The  KO  selects  a 
contracting  strategy  which  provides  the  optimum  balance  of  the  following: 

(1)  Minimized  total  system  life  cycle. 

(2)  Minimized  DON  risk,  liability,  and  obUgation  under  contract. 

(3)  Maximized  flexibility  to  meet  changing  DON  requirements. 

(4)  Maximized    ability    to    take    advantage    of   advances    in    ADP    technology. 
[Ref  15:  p.  4]        ' 

The  KO  does  not  develop  the  contracting  strategy  independent  of  the  PM.  The 
degree  of  teamwork  evidenced  between  the  KO  and  the  PM  during  this  phase  of  the 
acquisition  process  will  often  reflect  the  success  of  the  overall  program.  The 
frustration  end-users  experience  is  generally  aimed  at  the  KO  simply  because  the  end- 
users  are  the  most  divorced  from  the  functional  process  in  the  contracting  arena.  Ihe 
PM  must  bridge  the  gap  between  the  end-users,  the  sponsors  and  the  KO.  All  of  the 
participants  in  acquisition  planning  need  to  appreciate  the  parameters  the  KO  works 
within.  The  acquisition  strategy  plan  is  the  physical  document  acting  as  the  bridge 
between  the  end-user's  need  and  the  contract  s. 

The  KO  must  interchange  certain  key  information  with  the  PM.  'I'his 
information  includes  the  the  system  alternative  s  to  be  pursued,  the  related  acquisition 
methods,  the  prioritized  system  objectives,  and  the  relevant  conditions  which  aflect  the 
acquisition  [Ref  16:  pp.  16-18). 

Based  on  this  key  information,  the  KO  (in  concert  with  the  PM)  determines  the 
contract  type  most  appropriate  for  each  deliverable  identified  in  the  system  acquisition 
strategy  plan. 

The  following  are  the  basic  contract  types  available  to  the  KO: 

1)  Firm  Fixed  Price 

2)  Fixed  Price  Incentive 

3)  Fixed  Price  with  Economic  Price  Adjustment 
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4)  Cost  Reimburseable 

5)  Cost  Plus  Fixed  Fee 

6)  Cost  Plus  Award  Fee 

7)  Cost  Plus  Incentive  Fee 

This  determination  is  only  the  'tip  of  the  iceberg',  the  KO  must  also  consider  the 
following  contract  provisions  when  developing  a  contract: 

1)  Warranty  Issues 

2)  Pre-Production  Evaluation 

3)  Investment  Protection 

4)  Design  To  Cost 

5)  Value  Engineering 

6)  Data  Rights  Clause,  s 

7)  Pre-Award  Survey 

8)  Post-y\ward  Conference 

The  complexity  does  not  diminish,  the  PM  and  KO  must  also  acquire  the 
resources  needed  within  the  timeframes  desired  by  the  users,  within  the  guidelines 
provided  by  higher  authority,  within  the  parameters  of  competition  and  under  the 
constant  eye  of  public  scrutiny. 

E.       SCOPE 

The  scope  of  IS  acquisition  planning  is  limited  by  a  number  of  parameters.  First, 
it  does  not  apply  to  the  development  of  all  information  systems.  Extensive 
maintenance  and  'minor'  revisions  to  existing  information  systems  are  allowed.  There 
are  no  specific  thresholds  defining  where  system  improvements  transition  from  revision 
to  new  development.  Acquisition  planning  is  not  required  for  minor  revisions,  it  is  for 
new  development. 

Second,  the  defmition  of  information  systems  is  a  factor  limiting  the  scope  of  IS 
acquisition  planning.  Information  systems  definitions  vary  widely,  but  contain  a 
common  thread.  That  common  thread  is  that  an  information  system  must  use  ADPE 
to  store,  manipulate,  transmit  and  or  receive  data/information.  Recent  amendments  to 
the  Brooks  Bill  have  clarified  it's  scope  to  mesh  with  this  wider  definition  of  an  IS.  This 
clarification  reflects  the  merging  of  ADP  and  communications  technologies  [Ref  23:  p. 
759].     The  current   definition   of  ADPE   has   been   broadened  "...   to   mean  any 


20 


equipment  or  interconnected  system  or  subsystems  of  equipment  that  are  used  in  tlie 
automatic  acquisition,  storage,  manipulation,  management,  control,  display,  svvitchimg. 
interchange,  transmission,  or  reception  of  data  or  information,  including 
communications"  [Ref  23:  p.  759].  IS  acquisition  planning  for  tactical  systems  is  the 
most  significant  area  excluded  due  to  current  definitions. 

Third,  a  formal  acquisition  strategy  plan  is  not  required  for  all  IS  developments. 
The  question  of  applicability  is  not  precise,  but  is  basically  bounded  by  the  regulator}' 
requirements  for  an  acquisition  plan.  The  FAR  and  NARSUP  require  that  acquisition 
plans  be  prepared  for: 

(1)  Any  development  acquisition  whose  total  cost  exceeds  S2  million. 

(2)  Anv  production  acquisition  whose  contractual  cost  exceeds  S15  million  for 
total  life  cycle  of  S5  million  for  any  single  fiscal  year. 

Acquisition  plans  are  not  required  for: 

(1)  Militar\' Construction 

(2)  Spare  and  Repair  Parts 

(3)  Overhaul.  Repair  and.  or  Modification  of  Xaval  Ships  and  Craft 

(4)  Component    Overhaul  Maintenance  Repair    at    the    Depot,    Intermediate    or 
Organizational  Level 

(5)  For  Acquisitions  Which  Represent  a  Final  or  One-time  Buy 

(6)  For  General  Service  Contracts,  such  as  an  Omnibus  Contract 

(7)  Commercial  Activities 

Finally,  the  scope  of  acqisition  planning  is  limited  in  it's  distribution.  The  fact 
that  the  contents  of  acquisition  strategy  plans  is  considered  privileged  information 
limits  the  dissemination  of  these  plans.  This  also  implies  that  acquisition  strategy  plans 
should  be  prepared  internally  to  DOD  (SECNAVINST  5570. 2B  provides  amplifying 
information).  This  business  sensitivity  associated  with  acquisition  strategy  plans  means 
that  DOD  personnel  are  limited  in  what,  when  and  how  they  discuss  acquisition 
strategy  with  contractors.  Neither  the  information  contained  in  an  acquisition  strategy 
plan  nor  copies  of  an  acquisition  strategy  plan  may  be  provided  to  contractors  (if  this 
information  could  provide  an  advantage  to  a  contractor). 
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Figure  2.1     Acquisition  Planning  Process. 
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III.  OVERVIEW  OF  MAJOR  INFORMATION  SYSTEMS 

A.       DEFINITIONS 

In  order  to  analyze  major  information  system  acquisitions  it  is  necessan.-  to 
define  what  a  major  information  system  acquisition  is.  The  OHice  of  Management  and 
Budget  (OMB)  and  the  General  Services  Administration  (GSA)  jointly  publish  a 
compilation  of  Federal  executive  agency  plans  for  major  acquisitions  of  information 
technology  systems,  facilities,  and  related  services.  The  acquisition  plans  listed  cover 
computer  and  teleconmiunications  systems  as  defmed  in  Section  43  of  OMB  Circular 
No.  A-U.  This  compilation  is  documented  annually  as  a  five-year  plan  [Ref  24:  p.  i]. 
Volume  II  of  this  document  deals  with  major  information  technology  systems 
acquisition  plans.  Major  systems  acquisition  plans  for  the  Department  of  Defense  are 
defined  in  this  volume  as  "acquisitions  which  have  a  five  year  planned  cost  o{^  more 
than  .  .  .  eight  million  dollars  "  [Ref  24:  p.  I]. 

There  are  numerous  other  definitions  of  a  major  information  system.  The 
Department  of  Defense  defines  a  major  automated  information  system  in  DODD 
7920.1.  DODD  7920.1  identifies  an  automated  information  system  (AIS)  as  "a 
collection  of  functional  user  and  ADP  personnel,  procedures  and  equipment  (including 
ADPE)  which  is  designed,  built,  operated  and  maintained  to  collect,  record,  process, 
store,  retrieve,  and  display  information  [Ref  18:  p.  2]. 

A  major  AIS,  per  DODD  7920.1,  is  an  AIS  which  meets  any  one  of  the 
following: 

(1)  Has  anticipated  costs  in  excess  of  SlOO  million  from  Mission  Analysis,  Project 
Initiation  through  Deployment. 

(2)  Has  estimated  costs  in  excess  of  S25  million  in  any  single  year. 

(3)  Is  desisnated  as  beins  of  special  interest  by  the  OlTice  of  the  Secretarv  of 
Defense  (OSD)  [Ref  I'S:  p.  31. 

Quixotically,  the  Department  of  Defense  defines  major  systems  seperately  from 

major  information  systems.    DODD  5000.1   designates  a  system  as  a  major  system 

based  upon: 

(1)  Development  risk,  urgency  of  need  or  other  items  of  interest  to  the  Secretan.- 
of  Defense. 

(2)  Joint     acquisition     of    a     svstem    bv     the     Department     of    Defense     and 
representatives  of  another  na'tion.  or  by  two  or  more  DOD  components. 
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(3)  Estimated  costs  in  excess  of  S200  million  (RDT&E)  or  SI  billion 
(procurement). 

(4)  Significant  congressional  interest  [Ref.  25:  pp.  5-6]. 

This  variance  between  a  major  system  and  a  major  information  system  causes 
additional  confusion.  The  life  cycle  documentation  required  for  a  major  system  is 
similar,  but  not  identical  to  that  required  for  a  major  AIS. 

The  Department  of  the  Na\T  adds  to  this  confusion.  The  Navy  identifies  an 
information  system  based  on  a  functional  classification.  Using  this  classification,  all  ISs 
which  use  computer  resources  are  assigned  to  a  specific  \a\7  directive.  The 
appropriate  directive  is  either  SECNAVINST  5000. IB  or  SECXAVINST  5231. IB, 
based  on: 

(1)  ISs  designated  as  major  svstems  bv  SECDEF  using  DODD  5000.1  use 
SECNAVINST  5000.115  regardless  of  functional  classification. 

(2)  ISs  in  functional  class  'A',  administrative  loeistic  svstems  and  all  ISs  not 
classified  elsewhere,  use  SECNAVINST  523 1. IB. 

(3)  ISs  in  functional  class  'B',  crvptoloeic  and  non-direct  support  intelligence  and 
communications  systems,  use'SECNAVINST  5231. IB. 

(4)  ISs  in  functional  class  'C.  weapons,  command  and  control,  direct-support 
intellisence  and  communications,  operations,  surveillance,  reconnaissance  and 
electronic  warfare,  use  SECNAVINST  5000. IB. 

The  P\I  faced  with  a  multiplicity  of  references  must  be  familiar  with  all  the 

references.  Indeed,  the  applicability  of  references  often  varies  during  the  Ufe  of  a  system 

based  upon  higher  authority  interests. 


B.       SYSTEMS  AND  DESCRIPTIONS 

DON  major  information  systems  acquisition  plans  for  the  period  19S6-I991 
number  one-hundred  thirty-one  (per  OMB  and  GSA).  These  plans  encompass  both 
tactical  and  non-tactical  systems  [Ref  24:  pp  37-61].  This  number  is  somewhat 
deceptive.  A  major  system  acquisition,  such  as  the  Uniform  Automated  Data 
Processing  System  -  Inventory  Control  Points  (UADPS-ICP),  encompasses  multiple 
major  system  acquisition  plans.  UADPS-ICP  includes  four  seperate  major  acquisition 
plans:  (1)  ICP  Resolicitation  -  OHice  Automation,  (2)  Competitive  Replacement  of 
Central  Computing  Facility,  (3)  Vlinicomputers  to  Support  DDN  Interface  and  (4) 
ADPE  Time.  This  example  clearly  illustrates  the  fact  that  the  number  of  major 
information  systems  is  significantly  less  than  the  the  number  of  acquisition  plans.  Part 
of  the  confusion  occurs  because  of  terminoloev  differences.    For  ease  of  understanding. 
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equate  acquisition  strategy  plans  with  the  acquisition  of  a  major  sytem,  and  acquisition 
plans  with  the  contracting  plans  for  subsystems  of  that  major  system. 

The  total  number  of  administrative  logistic  major  systems  listed  by  0MB  and 
GSA  was  twenty-one.  Acquisition  strategy  plans  for  seven  of  these  were  obtained  in 
time  to  be  analyzed  for  this  thesis.  Appendix  B  lists  the  representative  major  systems 
considered  for  this  thesis  [Ref  24:  pp.  37-61].  Discussions  with  personnel  familiar  with 
the  acquisition  plans  not  received  revealed  similar  acquisition  strategy  plan  content. 

C.       DISCUSSION 

Current  major  information  systems  encompass  a  wide  variety  of  acquisition 
planning  considerations.  This  section  is  intended  to  identify  those  aspects  of  current 
major  system  acquisitions  which  are  judged  by  their  respective  PMs  as  successful. 
Observations  and  conclusions  are  drawn  from  these  comments  to  identify  generic 
trends  and  actions  which  could  be  incorporated  in  future  major  information  system 
acquisitions. 

The  major  system  acquisition  plans  were  similar  in  format.  All  plans  were 
contract  oriented  (i.e.  over  fifty  percent  of  the  plans'  content  dealt  with  contractual 
issues).  Contracting  is  a  subset  of  acquisition,  but  is  differentiated  herein  for  purposes 
of  analysis.  Contracting  deals  with  the  details  of  preparing  the  actual  contract  and  the 
contract  itself  The  remainder  of  the  acquisition  strategy  plan  deals  with  strategy 
issues.  Strategy  issues  are  concerned  with  system  objectives  and  alternatives,  such  as  in- 
house  versus  contractor  developed  software.  It  is  primarily  these  strategy  issues  which 
this  thesis  addresses. 

The  acquisition  strategy  plans  for  major  information  systems  can  be  grouped  into 
three  categories: 

(1)  Hardware-oriented  acquisitions. 

(2)  Application-oriented  acquisitions. 

(3)  Combination  of  hardware-oriented  and  software-oriented  acquisitions. 
Hardware- oriented  acquisitions  are  represented  by   ICP   RESPRO,   SPAR  and 

SPLICE.  Application-oriented  system  acquisitions  include  APADE,  L'ADPS-ICP. 
UADPS-SP  and  CAIMS.  Combinational  system  acquisitions  are  best  represented  by 
SNAP  I  and  SNAP  II. 
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This  categorization  particularly  highlights  the  question  of  competitiveness.  The 
application-oriented  system  acquisitions  are  relatively  free  of  the  pressures  to  obtain 
'free  and  open  competition'.  This  is  as  a  result  of  structure.  Applications-oriented 
systems  posit  a  fixed  operating  environment  and  then  solicit  vendors  who  can  satisfy  a 
requirement.  Hardware-oriented  systems  can  not  present  a  fixed  environment  without 
vendors  challenging  competitiveness. 

How  current  major  information  system  acquisitions  have  dealt  with  the  question 
of  competitiveness  is  varied.  One  trend  which  has  gained  significant  support  is  the  use 
of  'plug  compatability'.  By  specifying  the  need  for  hardware;  system  software  to  be 
plug  compatible  with  existing  hardware  the  PMs  have  argued  that  sufficient 
competition  is  available  to  meet  Congressional  requirements.  This  has  not  been 
conclusively  documented,  but  the  trend  to  use  plug  compatabiUty  in  acquisition 
planning  is  evident.  The  use  of  plug  compatabiUty  is  thus  one  improvement  evidenced 
in  current  acquisition  planning. 

The  ICP  Resolicitation  project  (ADPSO  Project  Number  81-35)  introduced  a 
number  of  improvements  to  the  ADP  system  acquisition  process.  The  application  o[ 
weapon  system  acquisition  techniques  to  the  ADP  acquisition  process  has  been  the 
most  successful  of  these  improvements.  The  use  of  a  two-phase  procurement  and  a 
twenty-four  year  system  life  with  technology  updates  are  the  primarv'  features  of  this 
approach.  A  reduced  technological  life  for  information  systems  is  viewed  as  necessary 
by  most  PMs. 

The  use  of  the  'single  vendor  responsibility'  concept  is  displayed  in  the  ICP 
RESPRO  acquisition.  This  feature  provides  for  a  system  integrator,  whereby  the 
chosen  vendor  is  required  to  provide  the  complete  integrated  hardware  and  system 
software  environment.  The  chosen  vendor  also  serves  as  the  'single  point  of  contact' 
with  the  government  regarding  all  aspects  of  the  operating  environment.  This  single 
vendor'  and  system  integration  have  become  generally  accepted  in  information  system 
acquisitions. 

The  specifications  for  the  ICP  RESPRO  hardware,  systems  software 
telecommunications  system  were  defined  as  an  aggregate  of  the  functional  requirements 
from  other  major  system  efforts.  These  functional  requirements,  expressed  in  the 
individual  requirements  statements  (RS),  were  developed  for  each  module  application 
of  the  CAIMS  and  UADPS-ICP  systems.  Then  these  seperate  RSs  were  combined  in 
order  to  justify  the  sizing  of  the  ICP  RESPRO  effort. 
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SNAP  II  is  procuring  non-developmental  item  (NDI)  hardware  and  developing 
the  application  programs  in-house.  The  hardware  contract  was  awarded  under  the 
provisions  of  Section  8(a)  of  the  Small  Busisness  Act.  The  vendor  was  designated  as 
the  single  system  integrator.  The  use  of  a  single  system  integrator  is  increasingly  being 
used  to  ease  IS  management  problems.  The  use  of  a  single  system  integrator  relieves 
the  government  of  the  major  problem  of  integrating  hardware,  system  software  and 
peripheral  equipment  from  multiple  vendors. 

The  grouping  of  hardware  requirements  for  multiple  major  application  systems  is 
increasing.  The  Stock  Point  ADPE  Replacement  (SPAR)  project  uses  a  similar 
justification  for  upgrading  the  hardware  and  the  system  software  st  the  Na\w  stock 
points.  APADE  makes  use  of  hardware  system-software  being  acquired  under  the 
Stock  Point  Logistics  Integrated  Communication  Environment  (SPLICE)  project. 

The  Shipboard  Non-Tactical  ADP  Program  (SNAP)  is  a  two-part  program. 
SNAP  I  is  replacing  the  hardware  and  system  software  on  large  ships,  Marine  Air 
Groups  and  selected  shore  sites.  SNAP  II  is  providing  the  initial  non-tactical  ADP 
capability  to  all  other  ships  and  submarines  that  do  not  have  this  capability. 

This  segregation  by  ship  size  was  believed  to  ease  competing  political  pressures. 
The  segregation,  by  diversifying  interests,  was  able  to  group  similar  ships  based  on 
similar  requirements.  Each  community  (e.g.  submarines,  destroyers,  carriers,  etc.)  has 
identified  unique  requirements.  The  ability  to  provide  for  these  requirements  within 
system  boundaries  is  difiicult. 

One  means  of  dealing  with  unique  requirements  has  been  by  incorporating 
var\"ing  configurations  within  one  major  system.  The  SNAP  II  submarine 
configuration  has  incorporated  the  use  of  intelligent  terminals  (microcomputers)  as 
integral  to  the  design  configuration.  This  use  of  intelligent  terminals  vice  the  dumb' 
terminals  in  surface  ships  adds  fexibility  for  the  applications  designers  and  handles  the 
unique  requirements  of  the  submarine  community. 

SNAP  I  was  awarded  competitively  with  a  firm  fixed  price  contract.  The  use  of 
firm  fixed  price  contracts  is  increasingly  being  used  in  the  acquisition  strategies  for 
administrative  logistic  information  systems.  This  has  been  possible  due  to  two  primary 
factors:  (1)  the  ability  to  use  plug-compatible  specifications,  and  (2)  the  ability  to 
logically  seperate  design  phases  in  IS  development.  Integrated  Logistic  Support  (ILS). 
including  site  preparation  and  installation  support  being  provided  by  a  seperate  vendor 
in  the  case  of  SNAP  I  is  one  example.  ILS  is  now  considered  a  mandatory  element  of 
any  major  information  system  acquisition. 
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SNAP  I  is  also  obtaining  the  hardware  to  support  the  Naval  Air  Logistics 
Command  Management  Information  System  (NALCOMIS).  The  issue  of 
coordination  between  major  sytems  is  a  vital  aspect  of  current  acquisition  strategies. 
This  meshing  of  various  major  information  systems  does  blur  individual  system 
boundaries.  Risk  for  both  projects  is  thus  magnified  by  increasing  the  mutual 
dependencies  of  both.  Most  PVIs  favor  this  due  to  the  reduction  of  aggregate  risk.  If 
any  one  project  is  successful  it  can  serve  as  justification  for  continued  support  of  other 
projects,  because  of  inter-dependencies. 

The  Automation  of  Procurement  and  Accounting  Data  Entry  (APADE)  system 
meshes  contractor  and  in-house  efforts  very  successfully.  A  competitive  contract  was 
awarded  to  prepare  the  Data  Requirements  Document  (DRD).  System/Subsystem 
Specifications  (SS)  and  Database  Specifications  (DS)  draft  documents  for  the  system. 
This  portion  of  administrative,  logistic  systems  development  is  normally  done  in-house. 
For  APADE,  these  documents  were  developed  given  a  government-imposed  operating 
environment  (hardware  and  system  software). 

The  Conventional  Ammunition  Integrated  Management  System  (CAIMS)  uses  a 
two-phased  process  for  acquiring  applications  sosftware.  Hardware  and  system 
software  is  being  provided  under  ICP  RESPRO.  CAIMS  illustrates  the  redesign  of  an 
existing  system.  The  Functional  Descriptions  (FD)  and  System  Subsystem 
Specifications  (SS)  are  being  developed  in-house.  Contractor  support  is  being  used  for 
programniing  and  the  remaining  life  cycle  management  documentation.  This  illustrates 
the  general  use  of  contractor  support  in  Navy  administrative/logistic  system 
development. 

The  use  of  contractors  in  more  of  the  phases  of  information  systems  development 
is  not  a  uniform  trend,  but  it  is  a  trend.  The  abihty  to  obtain  the  correct  mix  of 
technical  skills  quickly  and  easily  using  contract  line  items  is  almost  a  necessary 
requirement. 

The  Fleet  Material  Support  Office  (FMSO)  is  designated  as  the  Central  Design 
Agency  (CDA)  for  APADE.  As  a  CDA,  FVISO  is  responsible  for  design,  development 
and  implementation  of  the  system.  FVISO  is  designated  the  Na\7  CDA  on  most  major 
administrative/logistic  information  sytems. 

The  Defense  Logistics  Agency  (DLA)  uses  a  single  CDA  for  all  major 
information  system  developments.  The  Navy  uses  multiple  CDAs.  The  benefits 
associated  with  a  single  CDA  or  multiple  CDAs  is  beyond  the  scope  of  this  thesis.  The 
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use  of  a  CDA  is.  however,  a  necessan'  element  of  a  successful  niajor  information 
system. 

The  use  of  contractor-provided  software  maintenance  is  widely  used  in  major 
weapon  systems.  It  is  generally  not  used  for  applications-oriented  information  system 
development.  .-XPADE  incorporates  contractor-provided  software  maintenance  for  one 
year  after  implementation  of  the  APADE  system  at  the  last  APADE  site.  .Although  not 
an  ongoing  effort,  AP.ADE's  use  of  contractors  for  software  maintenance  is  a  good 
example  of  the  diversity  of  contractor  support  available. 

The  SPLICE  project  consolidates  the  telecommunications  hardware  at  various 
Na\y  activities.  The  use  of  a  centralized  distributed  processing  network,  using  a 
standard  protocol  is  the  primar\'  benefit  of  SPLICE.  The  success  of  SPLICE  could 
provide  a  model  for  future  integrated  sytem  elTorts. 

The  fact  that  the  major  information  systems  reviewed  for  this  thesis  were  limited 
in  number  is  a  pertinent  fact.  It  is  somewhat  compensated  for  by  the  observations 
provided  by  the  PMs.  These  observations  encompassed  Na\w-wide  trends  and  used 
individual  major  information  systems  primarily  as  examples. 

The  discussions  with  the  PMs  also  introduced  the  question  of  applicability.  The 
extent  to  which  current  major  systems  apply  new  acquisition  planning  trends  is  often  a 
result  of  higher  authority,  as  opposed  to  a  PM's  innovation.  In  other  words,  senior 
Na\w  officials  pick  developing  projects  and  encourage  the  particular  PM  to  use  a 
specific  strategy  as  a  test.  This  was  not  able  to  be  substantiated,  but  fits  observed 
acquisition  efTorts. 
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IV.  ACQUISITION  STRATEGY  ANALYSIS 

A.       INTRODUCTION 

Within  DOD  there  is  no  standard  acquisition  strategy.  'There  is  no  common 
working  defmition  of  'acquisition  strategy',  or  any  consistent  agreement  on  its 
structure  and  composition;  nor  is  there  comprehensive  guidance  on  how  to  proceed  in 
developing  and  executing  an  acquisition  strategy"  [Ref.  8:  p.  l-l]. 

Acquisition  strategy  for  major  systems  is  generally  embodied  in  a  physical 
document  called  the  acquisition  strategy  plan.  The  acquisition  strategy  plan  may  van.' 
in  length,  but  generally  is  contained  in  less  than  twenty  pages.  It  describes  the 
resources  required  for  the  system  and  how  those  resources  will  be  acquired.  The 
acquisition  plan  is  a  roadmap  to  assist  the  PM  in  obtaining  the  necessary  resources  for 
his  her  program. 

Various  instructions  detail  the  content  of  an  acquisition  strategy  plan. 
Appendices  E  through  I  identify  the  var\'ing  contents  of  acquisition  plans.  The 
contents  are  based  on  various  acquisition  planning  regulations  within  the  Federal 
government.  As  is  readily  apparent,  no  single  guidance  encompasses  all  the 
requirements  a  PM  must  consider.  The  fact  that  a  PM  must  select  the  appropriate 
format  from  among  varying  options  adds  to  the  difficulty  of  a  PM's  job.  It  should  be 
remembered  that  the  selection  of  the  appropriate  format  is  not  a  question  solely  of 
choice.  The  selection  and  application  of  the  var\"ing  guidance  and  formats  is  primarily 
driven  by  the  program  iteself.  The  scope,  thresholds  and  interest  a  particular  program 
generates  is  the  determinant  (as  previously  discussed). 

Difficulty  in  developing  an  acquisition  strategy  is  a  common  problem.  The 
starting  point  for  most  PMs  is  the  acquisition  strategy  plan.  PVI's  generally  begin  with 
the  mission  need  determination.  This  provides  the  PM  with  a  rough  approximation  of 
the  system's  cost.  The  PM,  in  most  cases,  also  knows  the  how  the  sponsor's  want  the 
acquisition  strategy  designated.  This  occurs  because  the  functional  sponsor  assigns  the 
PM.  From  this  point  on,  the  PM  must  walk  a  fine  line.  Most  PMs  have  succeeded 
because  they  were  able  to  handle  tradeoOs  between  sponsor's  wants  and  the  systems 
requirements. 
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B.       BASIC  ELEMENTS/  COMPONENTS 

The  basic  elements  of  an  acquisition  strategy  plan  van'.  The  variations  are 
primarily  a  matter  of  specificity  (compare  appendices  E  through  1).  NA\'DAC 
includes  the  acquisition  strategy  plan  as  an  annex  to  the  Project  Vlanagement  Plan 
(PMP)  [Ref.  26;  p.  ii].  Whether  as  part  of  a  PMP  or  as  part  of  a  SDP.  the  acquisition 
strategy  plan  encapsulates  the  basic  components  of  acquisition  planning.  The 
following  outlines  the  basic  content  of  an  acquisition  strategy  plan  at  the  various 
stages  in  the  life  cycle  of  an  information  system: 

1.     Milestone  I  Documentation  Requirements 

a.  Acquisition  Description  {limit  to  four  or  five  sentences) 

b.  Resource  Sources  (contractor  versus  in-house) 

c.  Cost  Estimate 

d.  Proposed  Funding  Method 

e.  Estimated  Contract  Life 

f.  Acquisition     POA&\L     showing     projected     completion     dates     for    the 
following: 

( 1 )  Specifications 

(2)  Obtaining  Delegation  of  Procurement  Authority  (DPA) 

(3)  Issuing  Requests  for  Proposals  (RFPs) 

(4)  Awarding  Contract 

(5)  Installation  and  Acceptance  (ADPE/data  communications  equipment 
onlv) 


Milestone  II  Documentation  Requirements 

a.      Update     acquisition     descriptions     from     Milestone     I,     considering     the 
following: 

(1)  Updating  definition 

(2)  Updating  resource  sources 

(3)  Is  a  conversion  study  required 

(4)  Means  for  obtaining  resources;  e.s.  turn-kev.  requirements  contracts. 
GSA  schedule,  full  competition,  liniitcd  competition,  or  sole  source. 


3.     Milestone  III  Documentation  Requirements 

a.  Update  to  show  contract  award  (whic 
stage) 

b.  Update  to  refiect  implementation  schedule 


a.      Update  to  show  contract  award  (which  should  be  accomplished  at  this 
stase) 


4.     Milestone  IV  Documentation  Requirements 

a.  Update  installation  schedule 

b.  Identify  planned  technology  updates 

c.  Schedule  exercising  contract  options 

d.  Identify  contract  replacement  renewal  date  [Ref  26:  pp.  37-39] 
Remember,    the    acquisition    strategy   plan    is    a    seperate   document    from   the 

acquisition  plan.  The  acquisition  plan  is  a  subset  of  the  acquisition  strategy  plan.  The 
acquisition  strategy  plan  is  developed  by  the  Program  Manager  (PM).  whereas  the 
acquisition  plan  is  developed  by  the  Contracting  Officer  (KO).  Ever\'  major  system  has 
an  acquisition  strategy  plan  and  generally  multiple  acquisition  plans  for  the  various 
phases  steps  in  the  acquisition  strategy  plan. 

C.       CONCEPTUAL  FRAMEWORK 

The  conceptual  framework  for  the  development  of  an  acquisition  strategy  for 
major  Navy  information  systems  is  to  view  the  development  process  as  an  iterative 
process  of  tailoring.  The  acquisition  strategy  plan  should  provide  a  matrix  for  the 
integration  and  coordination  of  the  efforts  of  all  personnel  engaged  in  the  management 
of  the  acquisition.  Using  the  guidance  provided  by  DOD  and  DON  instructions,  a  PM 
should  develop  an  acquisition  strategy  plan  with  the  intent  to  describe  the  resources 
required  and  how  those  resources  are  going  to  be  obtained  for  the  specific  system 
required. 

The  acquisition  strategy  plan  itself  which  accomplishes  this  should: 

(1)  describe  the  acquisition 

(2)  identify  the  source,  s  of  resources 

(3)  estimate  costs 

(4)  define  funding  methodology 

(5)  project  estimated  system  life 

(6)  develop  a  POA&M  for  the  acquisition 

In  tailoring  an  acquisition  strategy  plan  to  a  specific  program,  the  PM  is 
provided  with  an  acquisition  team.  While  the  size  and  composition  varies  with  the 
monetary'  size  and  importance  of  program,  it  is  the  responsibiUty  of  the  PM  to  form 
the  team. 
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The  acquisition  team  should  reflect,  and  if  possible  integrate  the  interests  and 
skills  of  the  following: 

1)  a  knowledgeable  contracting  olTicer 

2)  a  functional  user  representative  s  (both  management  and  end-user) 

3)  a  technician  s  (systems  analysts  and  developers) 

4)  a  business  financial  manager 

5)  any  other  parties  who  have  a  vested  interest  in  the  system 

The  P\I.  as  the  leader  of  the  acquisition  team,  has  significant  responsibilities. 
He  she  must  develop  a  charter,  thereby  obtaining  authority  and  defining  responsibility. 
The  PM  must  lay  the  groundwork  and  obtain  resources  from  the  program  sponsors  in 
a  matrixed  environment,  competing  with  other  programs  for  limited  resources.  The  PM 
must  be  the  program's  principal  advocate  and  at  the  same  time  comply  with  the  myriad 
rules  and  regulations  surrounding  him  her. 

The  PM  must  integrate  the  many  diverse  functional  requirements  and  at  the 
same  time  provide  for  meeting  the  regulatory  guidance  concerning: 

(1)  Competition 

(2)  Concurrency 

(3)  Data  Rights 

(4)  Design-to-Cost 

(5)  Incentives 

(6)  Source  Selection 

The  PM  is  given  extensive  lists  to  aid  him  in  developng  an  acquisition  strategy 
plan.  Appendix  D  illustrates  one  such  Ust  from  DODD  5000.2.  What  none  of  these 
lists,  regulations  or  guides  provide  the  PM  with  is  the  skills  knowledge  experience 
needed  to  imbue  an  acquisition  strategy  plan  with  the  tenets  required  for  success.  The 
best  assistance  provided  to  the  PM  are  lists,  requiring  that  the  acquisition  strategy 
refiect  such  aspects  as: 

( 1 )  Realism 

(2)  Stability 

(3)  Flexibility 

(4)  Resource  Balance  [Ref.  8:  p.  3-9] 
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While  these  aspects  of  the  development  efibrt  are  not  only  needed  to  satisfy  a 
written  requirement,  but  ultimately  determine  the  success  or  failure  of  the  PM,  they 
have  minimal  meaning  out  of  context.  The  program,  the  sponsors,  Congress,  and  the 
other  environmental  factors  generally  determine  the  meaning  of  realism,  stability,  etc. 

The  best  the  PVI  can  do  is  measure  success  or  failure  based  on  personal, 
subjective  grounds.  To  a  large  extent,  this  is  indeed  what  happens.  Systems  are 
implemented  and  then  those  aspects  of  the  acquisition  strategy  which  retrospectively 
worked  are  deemed  to  be  successful  elements  and  are  perpetuated. 

D.       PROBLEMS/SUCCESSES 

A  program's  success  or  failure  must  be  judged  based  upon  some  criteria.  The 
most  important  criteria  is  the  implementation  of  a  system.  The  criteria  which  best 
ensures  implementation  of  a  system  are: 

(1)  ReaUsm 

(2)  Stability 

(3)  Flexibility 

(4)  Resource  Balance  [Ref.  8:  p.  3-9] 

The  following  paragraphs  discuss  how  these  criteria  can  be  integrated  into  an  IS 
acquisition  strategy  plan. 

Realism 

Realism  is  a  measure  of  confidence.  It  is  not  easily  quantified,  but  it  does  have 
measureable  properties.  Ranking  and  statistical  tools  are  used  to  measure  confidence  in 
a  plan's  likelihood  of  being  implemented.  This  is  critical  in  order  to  obtain  continued 
support  during  the  approval  process.  The  use  of  third-party  validation  of  requirements 
and  estimates  is  the  most  accepted  means  of  proving  realism.  The  use  of  government 
laboratories  and  uninvolved  contractors  for  independent  confirmation  is  another  useful 
proof  of  realism.  The  acquisition  team's  composition  can  be  loaded  with  recognized 
experts,  to  add  to  the  plan's  reflecting  realism.  Increasingly,  the  use  of  third-party 
validation  is  essential  to  demonstrating  realism. 

Stability 

Stability  is  the  measure  of  an  information  system's  sensitivity  to  internal  and 
external  Hux.  An  acquisition  strategy  for  ISs  must  be  insulated  from  this  flux  to  the 


maximum  extent  possible.  Without  this  insulation,  the  system  is  too  easily  overturned. 
IS  programs  need  to  be  self-contained.  The  program  should  be  a  total  system, 
including  both  hardware  and  soitware.  Dependence  on  existing  resources  and  or 
external  support  mcreases  risk  to  the  program.  Stabilization  of  requirements  can  be 
achieved  by  properly  fencing  the  IS  program.  Contractual  guarantees  can  be  used  to 
ensure  life  cycle  support  of  contractor-provided  critical  items.  The  use  of  structured 
analysis  and  design  techniques  is  appropriate  to  add  to  the  stability  of  in-house 
software  development. 

Resource  Balance 

An  IS  project  should  be  composed  of  both  in-house  and  contract  facets.  The 
ability  to  augment  a  project  can  only  occur  if  the  project  has  inherent  growth  potential. 
Since  adding  in-house  personnel  is  diHlcult,  the  involvement  of  contractor  personnel 
insures  the  ability  to  quickly  respond  to  any  developing  crises.  The  broadened  base  of 
personnel  possible  by  involving  both  in-house  and  contractor  personnel  in  all  phases  is 
highly  beneficial.  Those  systems  which  have  included  the  widest  diOusion  of  resources 
have  also  proven  to  be  the  most  successful. 

Fle.xihiliiy 

FlexibiUty  is  the  most  important  aspect  of  an  acquisition  strategy  plan.  Flexibility 
is  critical  to  achieving  realism,  stabiUty  and  resource  balance.  Contract  flexibility  can 
be  achieved  by  dual-sourcing.  The  use  of  pre-planned  product  improvement  is 
absolutely  essential  due  to  the  rapidity  of  technological  change.  The  most  successful 
systems  currently  being  developed  use  an  eight  year  life  cycle.  The  Defense  Logistics 
Agency  (DLA)  has  improvd  upon  this  by  using  a  five  year  technological  life  for 
hardware-only  acquisitions.  Previous  systems  used  a  fiveteen  year  life  cycle.  The  eight 
year  life  cycle  adds  significantly  to  flexibiUty.  It  is  more  flexible  because  it  more  closely 
matches  the  technological  life  oi"  computer  hardware  development.  Contractual 
provisions  which  allow  for  interim  technology  upgrades  are  invaluable  today.  Contracts 
using  these  provisions  are  one  of  the  few  means  allowing  the  Navy  to  stay  abreast  of 
technology  advances. 

The  differentiation  between  tactical  and  non-tactical  evidences  the  recognition  of 
varying  requirements.  How  well  the  PM  matches  requirements  with  the  acquisition 
strategy  plan  determines  the  success  of  the  system.  The  more  difTerentiation  the  system 
allows,  the  more  flexibility  the  PVI  can  use  in  his  her  acquisition  planning. 
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Another  example  of  flexibility  is  the  use  of  "specialized  acquisition  procedures'. 
The  use  of  'specialized  acquisition  procedures'  exists  today.  The  wider  use  of  these 
procedures  has  been  endorsed  by  Senator  Sam  Nunn  [Ref  19:  p.  15].  This  procedure 
allows  wider  latitude  to  the  PM  in  documentmg  and  streamlining  the  acquisition 
process.  The  PVI  is  essentially  exempted  from  meeting  the  requirements  of  existing 
regulations.  Although  primarily  used  for  classified  systems,  the  recognition  of  these 
procedure's  benefits  establishes  the  rationale  for  expanding  it's  use. 

The  Na\T  has  succeeded  in  a  number  o[  ways.  The  ICP  Resolicitation  has 
succeeded  in  establishing  a  precedence  for  long-term  hardware  and  system  software 
support.  The  revisions  and  updates  to  the  various  directives  which  have  integrated 
ADP,  OA  and  telecommunications  show  the  Navy's  adaptabihty.  The  variance  in  the 
acquisition  strategy  plans  themselves  reveals  the  Xa\T's  flexibiltiy. 

The  senior  management  in  the  Department  of  Defense  recognize  the  importance 
and  the  challenges  of  being  a  PVI  [Ref  22].  This  recognition  adds  support  to  the 
ongoing  enhancements  now  occurring  in  the  Navy  IS  acquisition  arena. 
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V.  PROPOSED  ACQUISITION  STRATEGY 

A.       INTRODUCTION 

Proposed  changes  to  the  Navy's  acquisition  process  have  been  numerous.  This 
thesis  was  originally  intended  to  propose  sweeping  changes  as  well.  However,  during 
the  research  and  formulation  of  this  thesis  it  became  increasingly  clear  that  the 
bureaucratic  system  (so  often  criticized)  is  at  the  ver\"  least  a  dynamic  system.  The 
system  is  improving,  adapting  and  evolving  to  mesh  with  the  requirements  of  today. 

The  comparison  with  private  industrv-  is  not  totally  valid.  The  oft-used 
comparison  with  private  industn."  must  be  viewed  in  it's  proper  light.  The  Federal 
government's  information  systems  "...  dwarf  those  of  even  the  largest  private  sector 
users"  [Ref  6:  p.  VHI-14J.  This  size,  coupled  with  the  extreme  degree  of  visibility 
under  which  government  activities  take  place,  makes  comparisons  dillicuit.  It  doesn't 
make  them  impossible. 

Some  authors  have  argued  that  this  size  and  visibility  coupled  with  extant 
procurement  laws  and  regulations  preclude  the  Navy  from  emulating  private  industry 
[Ref  7:  pp.  S-9].  This  argument  has  minimal  merit.  The  Navy  doesn't  have  to  emulate 
private  industry  in  order  to  benefit  from  the  experience  of  private  industry.  Navy 
procurement  laws  and  regulations  are  continually  being  adapted.  These  adaptations 
have  generally  been  to  infuse  private  industry  techniques  into  the  Navw.  The  use  of 
NDI  is  one  clear  example  of  the  Naw's  using  private  industry'  experience.  The 
merging  of  ADP,  OA,  \VP  and  telecommunications  is  another  example. 

Additionally,  the  Department  Of  Defense  has  made  significant  improvements  in 
the  IS  acquisition  process  Recent  DOD  elTorts  to  improve  the  IS  acquisition  process 
have  included  the  following: 

(1)  Establishment  of  the  Software  Engineering  Institute  (SEI),  with  the  intention 
to  foster  software  technology  transition  breakthroughs. 

(2)  Issuance  of  DOD-STD-2167.  to  provide  a  standard  manasement  framework 
for  defense  IS  svstems  (specilicallv  addresses  post  deplovment  software 
support  (PDSS)  issues  and  reduces 'the  number  of  data  iteiiis  required  lor 
developing  software  from  lUO  to  25). 

(3)  Use  of  ADA  as  standard  hish  order  language  for  all  weapon  svstems 
[Ref  4:  p.3U]. 
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Not  all  of  these  elTorts  have  come  to  fruition.  SEI  is  not  fully  established  and  the 
use  of  ADA  is  only  required  for  new  requirements.  Existing  non-ADA  systems  are  not 
identified  for  conversion.  EfTorts  are  not  sufficient  alone,  execution  must  be  effective 
and  consistent. 

The  list  of  actions  to  improve  the  IS  acquisition  process  at  the  Navy's  level  is 
also  significant.    Recent  Navv*  actions  include  the  following: 

(1)  Centralization  of  acquisition  strategy  policy  formulation  under  ASN{S&L). 

(2)  Acquisition  streamlining  efTorts,  such  as  the  emphasis  on  NDI. 

(3)  The  consolidation  and  clarification  of  directives. 

(4)  Recognition  of  the  merging  of  ADP,  OA.  WP  and  Telecommunications. 

The  President's  Task  Force  on  Automated  Data  Processing  Office  Automation 
found  that  the  Federal  government  had  failed  to  develop  a  coherent  system  for  ADP 
planning  and  management  [Ref  6:  p.  VHI-14].  The  President's  Task  Force  on  the 
Department  of  the  Navw  recommended  that  the  "...  Navy  improve  management  of 
ADP  assets  and  functions  by  consolidating  reviews  for  the  ADP-approval  cycle, 
encouraging  purchase  of  general  purpose  computers,  making  full  use  of  delegated 
procurement  authority  and  umbrella  contracts,  and  establishing  an  oOlce  with  overall 
responsibihty  [Ref  6:  p.  VHI-88]. 

The  Navy  is  addressing  these  concerns  aggressively.  The  recent  revisions  of  Navy 
and  DOD  regulations  have  streamlined  ADP  planning  and  management.  The 
placement  of  the  Contracts  and  Business  Vlanagement  (CBM)  organization  (what  was 
ONAS)  directly  under  the  Assistant  Secretary"  of  the  Navy  for  Shipbuilding  and 
Logistics  has  increased  the  visibility  and  scope  of  the  acquisition  planning  effort  in  the 
Navy.  Further,  almost  all  of  the  Navy  regulations  on  planning  and  management  of  ISs 
has  been  revised  in  the  last  year. 

The  Task  Force  on  ADP,  OA  also  identified  the  fact  that  the  average  age  of 
government  computers  is  almost  twice  that  of  the  private  sector  experience  [Ref  6:  p. 
VHI-15]. 

The  current  hardware- oriented  major  systems  will  replace  over  ninety  per  cent  of 
the  mainframes  in  the  Navy  administrative/logistic  area.  Thanks  to  'technology 
upgrades'  and  other  initiatives,  the  excessive  age  of  Nav\'  computers  should  not 
reoccur. 

The  efTorts  within  DOD  to  improve  the  acquisition  planning  process  are  paying 
dividends.  Publications  such  as  the  Program  Vlanager  and  the  Acquisition  Strategy 
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Guide  (although  weapon  system  oriented)  provide  a  wealth  of  information  to  as<;ist  the 
PM  [Ref  S].  These  basic  guidelines  lay  a  solid  foundation  for  the  PM,  hut  it  is  still  the 
PM's  responsibility  to  selectively  activate  those  principles  and  tenets  which  will  make 
his  her  acquisition  a  success. 

The  acquisition  strategies  being  used  in  the  Naw  today  are  continually  evolving. 
The  challenge  facing  the  NaNw  is  to  eflectively  execute  the  principles  of  acquisition 
strategy  development  which  have  been  identified.  The  argument  that  regulations  are 
too  restrictive  is  merely  an  excuse.  If  regulations  are  too  restrictive,  then  it  is  the 
Navy's  responsibility  to  modify  the  regulations  through  action. 

B.       PROPOSED  ACQUISITION  STRATEGY 

The  proposed  acquisition  strategy  which  provides  the  best  means  of  combating 
the  problems  the  Navy  faces  is  not  a  new  strategy  at  all.  Rather,  the  proposed 
acquisition  strategy  is  one  which  changes  the  emphasis  within  the  DON.  The  emphasis 
must  be  changed  to  one  of  clarifying  and  refming  the  the  regulations  and  guidance 
already  extant.    In  other  words  the  emphasis  must  be  placed  on  execution. 

Specifically,  initiatives  in  the  following  areas  will  provide  the  emphasis  needed  to 
improve  the  Navy's  IS  acquisition  planning: 

(1)  Simplification  of  acquisition  planning  requirements. 

(2)  Continued  expansion  of  the  use  of  NDI. 

(3)  Expanded  use  of  automation 

(4)  Easing  of  overly  restrictive  contracting  regulations. 

(5)  Expanding  the  use  of  contractor  support. 

The  following  paragraphs  will  discuss  each  of  these  initiatives  individually.  One 
common  theme  throughout  the  initiatives  is  flexibiUty.  Flexibility  must  be  inherent  in 
IS  acquisition  strategy  development. 

Simplijlcanon 

The  acquisition  strategy  plan  itself  needs  to  be  simplified.  Of  all  the  services,  the 
Na\'y  requirements  for  the  content  of  acquisition  strategy  plans  is  by  far  the  longest 
and  most  complex.  The  Army's  AR  70-1  requires  seven  elements  be  addressed  in  an 
Army  acquisition  strategy  plan.  The  Air  Forces  AFR  800-2,3  requires  thirteen 
elements  be  addressed  in  an  Air  Force  acquisition  strategy  plan  [Ref  8:  pp.  1-4  -  1-5). 
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Compare  this  with  the  twenty-three  elements  required  by  ONASINST  5200.29 
(Appendix  E).  or  the  thirty-one  major  elements  required  by  XARSUP  (Appendix  I). 
Admittedly,  simply  comparing  line-items  does  not  demonstrate  that  the  Navy 
acquisition  strategy  development  process  is  more  complex.  However,  the  combination 
ofthe  number  of  line-items  and  the  subjective  comments  from  Navy  PMs  does  indicate 
less  llexibility  than  is  available  to  the  PVIs  in  the  other  militarv'  services. 

The  required  content  of  an  acquisition  strategy  plan  should  be  as  minimal  as 
possible.  Each  individual  information  system  acquisition  should  be  individuallly  tailored 
to  it's  own  unique  requirements.  The  use  of  extensive  guides  should  be  at  the  discretion 
of  the  responsible  PM.  The  Navw  should  properly  place  the  responsibility  and  the 
commensurate  authority  on  the  PM's  shoulders  and  allow  him/her  to  function.  Most 
PM's  do  not  require,  nor  do  they  desire  having  their  hands  held. 

The  most  critical  aspect  of  an  acquisition  strategy  plan  should  be  some  type  of 
milestone  chart.  A  milestone  chart  introduces  discipline  into  the  process  in  a  graphic 
and  concise  form.  It  forces  consideration  of  all  factors  involved  in  the  acquisition  and 
also  provides  a  visual  portrayal  of  the  decisions  needed  to  achieve  the  program's 
objectives. 

The  specific  format  of  the  milestone  chart  should  be  as  unrestricted  as  possible. 
Regimentation  and  uniformity  have  their  place,  but  the  acquisition  strategy 
development  process  places  a  higher  premium  on  flexibility  and  adaptation.  Milestone 
charts  currently  only  identify  large  phases.  The  expansion  and  decomposition  of  the 
milestone  chart  should  be  linked  to  the  system's  development.  Currently  this  link  is  not 
required.  But,  this  link  must  be  accompanied  by  an  attitude  of  understanding.  If 
higher  authority  uses  the  milestone  chart  as  the  sole  means  of  judging  a  PVI's  success, 
no  improvement  to  the  acquisition  process  is  possible.  Not  meeting  a  deadline  must 
not  be  viewed  as  failure. 

"The  procurement  of  NDI  has  been  proposed  for  many  years  as  a  way  to  reduce 
program  costs,  shorten  the  time  required  to  field  operational  equipment  and  reduce 
program  risk"  [Ref  27:  p.  1].  The  use  of  NDI  can  significantly  shorten  the  acquisition 
time  and  increase  the  scope  of  competition  available  in  an  acquisition.  Whereas  in 
previous  years  the  use  of  NDI  was  rarely  used,  most  ofthe  current  systems  reviewed  in 
this  thesis  incorporate  NDI  in  the  hardware  portion  ofthe  acquisitions. 
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Indeed,  the  SECNAV  policy  is  now  to  "  .  .  .  institutionalize  NDI  considerations 
during  the  acquisition  process  to  such  an  extent  that  it's  use  becomes  the  rule  rather 
than  the  exception"  [Ref.  27:  p.  1].  This  policy  should  be  expanded  to  encompass  more 
than  hardware.  The  The  use  of  NDI  in  the  area  of  application  software  is  ripe  for 
expansion. 

Auioftuuion 

The  use  of  automation  in  the  acquisition  process  needs  to  be  emphasized. 
Current  efforts  to  provide  the  PM  with  a  decision  support  system  (DSS)  should  be 
expanded.  The  Program  Manager's  Support  System  (PMSS)  is  one  DSS  under 
development  [Ref.  2S:  p.  47].  It  is  intended  to  assist  PVIs  in  their  decision-making 
process.  This  Defense-level  elTort  should  be  mirrored  within  the  Navy  and  assigned  to 
a  specific  Na\y  otTice  for  further  development  and  tailoring. 

Coniruciing 

Improvements  in  the  area  of  contracting  are  sorely  needed.  Estimates  for 
obtaining  a  system  are  still  measured  in  years.  The  requirements  to  maintain 
competitiveness  and  allow  for  review  and  oversight  are  still  valid.  The  Navy  must 
innovate. 

Specific  improvements  should  center  on  reducing  the  approval  process.  The  use 
of  a  long  (twenty-plus  years)  contract  life  combined  with  frequent  (five  year  or  less) 
'technology  updates'  is  an  effective  approach.  Most  importantly  the  DOD  and 
Congress  must  recognize  a  technological  life  of  no  more  than  five  years  for  IS 
hardware  and  system  software.  IS  technology  is  changing  too  fast  to  place  a  bias 
towards  purchase  and  long-term  capital  depreciation. 

There  are  other  innovative  ideas  prevalent.  Ideas  to  shorten  the  announcement 
process  in  the  Commerce  Business  Daily  by  proposing  an  on-line  system  is  one  idea 
[Ref  29:  pp.  4(J-44].  The  base  for  this  and  other  acquisition  improvements  was  layed  in 
1981.  and  are  commonly  referred  to  as  the  Carlucci  initiatives  [Ref  30:  pp.  54-75]. 
While  a  great  number  of  Mr.  Carluccis  initiatives  have  been  implemented  fully,  others 
still  remain.  It  is  the  responsibility  of  all  Navw  acquisition  persoonel  to  further  this 
base. 
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Contractor  Support 

The  increased  use  of  contractor  support  throughout  the  spectrum  of  stages  in  the 
development  of  information  systems  should  be  explored.  Past  uses  of  contractor 
support  have  centered  on  the  later  stages  of  software  analysis  and  design  (i.e. 
programming  and  implementation).  The  whole  spectrum  of  the  analysis  and  design 
effort  should  be  used.  APADE  is  a  good  example  of  how  contractor  support  can  be 
used  in  the  early  stages  of  analysis  and  design,  specifically  the  development  of 
requirement  specifications. 

The  reason  for  increased  contractor  support  is  flexibility  and  innovation.  By 
using  contractor  support  in  a  variety  of  areas  the  Na\7  improves  it's  abiUty  to  identify 
and  incorporate  technological  advances.  The  Navy  also  gains  the  abihty  to  obtain 
highly  specialized  personnel  expertise  on  an  ad  hoc  basis.  This  selective  infusion  of 
experience  is  often  crucial  to  a  successful  program. 

In  conclusion,  the  Nav7's  IS  acquisition  process  is  improving  and  will  continue 
to  improve  as  long  as  the  system  is  allowed  to  function.  The  "unduly  close  supervision 
and  scrutiny  by  higher  levels  of  authority  .  .  .  characterized  by  the  term 
'micromanagement'  ..."  [Ref  7:  p.  21]  is  unnecessary*.  The  need  for  strong  central 
oversight  is  not  the  issue,  rather  the  issue  is  one  of  degree.  The  Na\7  must  have  the 
room  to  put  it's  own  house  in  order. 
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VI.  CONCLUSION 

The  Xav7  is  faced  with  an  ever  increasing  demand  for  the  expansion  oC  it's 
information  systems.  This  demand  is  increasing  at  the  same  time  that  personnel 
resources  are  dwindUng.  The  Navy  can  not  allow  regulations  and  policies  to  inhibit  IS 
growth. 

The  acquisition  planning  used  by  the  Navy  to  develop  and  maintain  effective  and 
etTicient  information  systems  is  critical.  An  acquisition  process  which  requires  three 
years  to  obtain  hardware  can  not  continue.  While  the  Navw  and  DOD  have  evidenced 
the  ability  to  adapt  the  acquisition  process  to  these  increasing  demands,  the  adaptation 
must  be  dynamic.  In  order  to  remain  dynamic  the  acquisition  process  must  provide 
flexibility,  stability,  resource  balance  and  realism.  Only  in  this  way  can  the  Navy  hope 
to  field  systems  responsive  to  future  needs. 
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APPENDIX  A 
LIST  OF  ACRONYMS  AND  ABBREVIATIONS 

ACAT  Acquisition  Category' 

ADP  Automated  Data  Processing   ^ 

ADPE  Automated  Data  Processing  Equipment    '^ 

AIP  Acquisition  Improvement  Program 

AIS  Automated  Information  System 

APADE  Automation  of  Procurement  and  Accounting  Data  Entr>' 

ARB  Acquisition  Review  Board 

ARC  Acquisition  Review  Committee 

ASDP  Abbreviated  System  Decision  Paper  ■" 

ASN(S&L)  Assistant  Secretan.-  of  the  Navy-  for  Shipbuilding  and  Logistics 

CAIMS  Conventional  Ammunition  Integrated  Management  System 

CDA  Central  Design  Agency 

CMC  Commandant  of  the  Marine  Corps 

CNO  Chief  of  Naval  Operations  - 

DAB  Defense  Acquisition  Board 

DAE  Defense  Acquisition  Executive 

DAIP  DOD  Acquisition  Improvement  Program 

DAR  Defense  Acquisition  Regulations   ^ 

DCP  Decision  Coordinating  Paper 

DG  Defense  Guidance 

DLA  Defense  Logistics  Agency 

DOD  Department  of  Defense 

DODD  Department  of  Defense  Directive  "^ 

DODI  Department  of  Defense  Instruction 

DON  Department  of  the  Nav\'  -^ 

DPA  Delegation  of  Procurement  Authority  "^ 

DRB  Defense  Resources  Board   -^ 

FAR  Federal  Acquisition  Regulations 

FD  Functional  Description 

FIPS  Federal  Information  Processing  Standards    ^ 
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FMSO  Fleet  Material  Support  OfTice 

FYDP  Five  Year  Defense  Program 

GAO  General  Accounting  Ofilce  - 

GSA  General  Services  Administration   "^ 

GSBCA  GSA  Board  of  Contract  Appeals 

HAC  House  Appropriation  Committee   ^ 

HBC  House  Budget  Comniittee 

ICP  Inventory  Control  Point  Resolicitation  Project 

ILS  Integrated  Logistics  Support 

IOC  Initial  Operational  Capability 

IS  Information  System  ^ 

JCS  Joint  Chiefs  of  Stall 

JVISNS  Justification  for  Major  System  New  Start 

KO  Contracting  Olficer 

MENS  Mission  Element  Needs  Statement 

NAE  Navy  Acquisition  Executive 

NARSUP  NaNT  Acquisition  Regulation  Supplement 

NDCP  Navy  Decision  Coordinating  Paper 

NDI  Non-Developmental  Item 

NSARC  Na\T  System  Acquisition  Review  Council 

OA  Office  Automation 

OMB  Office  of  Management  and  Budget 

OPNAV  Office  of  the  Chief  of  Naval  Operations 

OSD  Office  of  the  Secretary  of  Defense 

PDM  Program  Decision  Memorandum 

PM  Program  Manager  / 

PMP  Program  Management  Plan 

POA&M  Plan  of  Actions  and  Milestones   / 

POM  Program  Objective  Memorandum 

PPBS  Planning.  Programming,  and  Budgeting  System 

RFP  Request  for  Proposal    -- 

SCP  System  Concept  Paper 

SECDEF  Secretary  of  Defense    ^ 

SECNAV  Secretary  of  the  Navy 

SEI  Software  Eneineerine  Institute 
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•  SNAP  Shipboard  Non-Tactical  ADP  Program 

•  SPAR  Stock  Points  ADP  Replacement 

•  SPLICE  Stock  Point  Logistics  Integrated  Communication  Environment 

•  SS  System; Subsystem  Specifications 

•  SPR  Sponsor's  Program  Review 

•  SYSCOM  Systems  Command 

•  WP  Word  Processing 
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APPENDIX  B 
REPRESENTATIVE  MAJOR  NAVY  INFORMATION  SYSTEMS 


Intesrated  Disbursins  and  Accountine  Financial  Information  Processins  Svstem 
UDAFIPS)  ^  ^ 

Personnel  and  Pay  Systems  Consolidated  Computer  Center  (PERSPAY) 

Uniform    Automated    Data    Processing    Svstem    -    Inventon,'    Control    Points 
(LADPS-ICP)  ' 

Uniform  Automated  Data  Processing  System  -  Stock  Points  (UADPS-SP) 

Stock  Point  Logistics  Integrated  Communications  Environment  (SPLICE) 

Pav  Personnel      Administrative       Support       Svstem  Source       Data       Svstem 
(PASS  SDS) 

Naval         Air  Rework  Facilities         Workload         Control         Svstem 

(NAVAIRREWORKSFAC  WCS) 

Naval  Aviation  Logistics  Command  MIS  (NALCOMIS) 

Shipboard  Non-Tactical  Automated  Data  Processing  Program  (SN'AP-I) 

Shipboard  Non-Tactical  Automated  Data  Processing  Program  (SNAP-II) 

Department   of  the   Nav\-   OHlce   Automation   and   Communications   Svstem 
(DONOACS) 

Standard  Automated  Fmancial  System  (STAFS) 

GAG  Review  and  Approval  of  Accounting  Systems  Project  (GRASP) 

Na\7  Civilian  Payroll  System  Project  (NAVCIPS) 

Conventional  Ammunition  Integrated  Management  System  (CAIMS) 

Logistics     Application     of    Automated     Marking     and     Reading     Symbols 
(LOG  MARS) 

Inventory  Control  Point  Resolicitation  Project  (ICP  RESPRO) 
Stock  Point  ADP  Replacement  (SPAR) 

Printing  Resources  Management  Information  System  (PRIMIS-II) 
Naval  Aviation  Logistic  Data  Analysis  (NALDA)  System 
Automation  of  Procurement  and  Accounting  Data  Entry  (APADE) 


49 


APPENDIX  C 
MAJOR  IS  ACQUISITION  REFERENCES 


FEDERAL 


Public  Law  89-306  (Brooks  Bill),  30  October  1965 

Public  Law  98-191,  "Federal  Procurement  Policy  Act  Animendments  of  1983", 
1  December  1983 

Public  Law  96-511.  "Paperwork  Reduction  Act  of  1980",  11  December  1980 

Title  10  U.S.C.  2315  (Warner  Amendment),  1  December  1981 

0MB  Circular  A-109,  "Major  System  Acquisitions",  5  April  1976 

0MB  Circular  A-76,  "Comniercial  Activities  Program" 

Federal  Acquisition  Regulations  (FAR),  Part  7,  1  April  1986 

Federal  Property  Management  Regulations  (FPMR)  101-35.210,  "Management, 
Acquisition,  and  Utilization  of  ADP  Resources;  Evaluation  of  Acqliisition 
Alternatives", 

Various  FIPS  Standards  and  Guides 


DOD 


DOD  FAR  Supplement,  Part  7,  10  January-  1985 

DODD  5000.1,  "Major  System  Acquisitions",  12  March  1986 

DODD  5000.2,  "Major  System  Acquisition  Procedures",  12  March  1986 

DODD  5000.43.  "Acquisition  Streamlining",  15  January  1986 

DODD  7920.1.  "Life  Cvcle  Vlanagement  of  Automated  Information  Systems", 
17  October  1978 

DODD  7920.2,  "Major  Automated  Information  System  Approval  Process",  20 
October  1978  .  ^^ 


NA  VY 


N'avy  Acquisition  Regulation  Supplement  (NARSUP),  Part  7,  Januar}'  1986 

SECNAVINST  4210,  "Acquisition  Policy",  20  November  1985 

SECNAVINST  4210.7,  "Effective  Acquisition  of  Navy  Material",  16  June  1986 

SECNAVINST  5000. IB,  "System  Acquisition",  8  April  1983 

SECN.AVINST  5000.33,  "Project  Management  Proposal  Process",  6  September 
1985  J  ^  ^ 
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SECNAVINST    5230. S.    "Information    Processing    Standards    for    Computer 
Programs'.  10  May  1982  " 

SECNAVINST  5230. 9A.  "Information  Resources  (IR)  Prosram  Planning",   16 
October  1985  ^      '        ^ 

SECNAVINST    5231. IB.    "Life    Cvcle    Management    Policv    and    Approval 
Requirements  for  Information  System  Proiects",""8  .March  1985 

SECNAVINST  5236. IB.  "Contracting  for  Automatic  Data  Processing".  10  Mav 

1982  ^  .  -  ' 

SECNAVINST  5236. 2A,  "Automatic  Data  Processing  Services  Contracts".  7 
July  1980 

OPNAVINST  5000. 42C.  "Research  Development  and  Acquisition  Procedures". 
10  May  1986 

NAVMATINST  (ONASINST)  5000.29A.  "Acquisition  Strategy  Paper",  6  Mav 

1983  4  ..        1  . 

NAVDAC     Advisor\-     Bulletin     No.     70.     "Word     Processing    (WP),     Otlice 
Automation  (OA)  arid  Lile  Cycle  Management",  25  April  1985 

ADPSOINST  4235.  "Contracting  for  Automatic  Data  Processing  Equipment", 
21  June  1982 

NAVDAC  PUB  24.1  24.2.  "Life  Cvcle  Management:  Navy  Data  Automation 
Management  Practices  and  Procedures",  9  Mar'ch  1983 
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APPENDIX  D 
ACQUISITION  MANAGEMENT  AND  SYSTEM  DESIGN  PRINCIPLES 

1.  Mission  Analysis 

2.  Operational  Requirements 

3.  Long-Range  Planning  and  Program  Stability 

4.  AlTordability 

5.  Timeliness 

6.  Acquisition  Strategy 

7.  Participating  Activities 

8.  Industrial  Resource  Analysis 

9.  Facility  Construction 

10.  Cost  Estimates 

11.  Goals,  Thresholds,  and  Threshold  Ranges,  as  appropriate 

12.  International  Defense  Cooperation 

13.  Economical  Production  Rates 

14.  Test  and  Evaluation 

15.  Independant  Cost  Analysis 

16.  Competition 

17.  Specification  and  Standards 

IS.  Standardization  and  Interoperability 

19.  Preplanned  Product  Improvement 

20.  Quality 

21.  System  Readiness,  Support  and  Personnel 

22.  Reliability  and  Maintainability 

23.  Deployment  Requirements 

24.  System  Safety 

25.  Physical  Security 

26.  Nuclear  and  Chemical  Hardness,  Survivability  and  Endurance 

27.  Producibility  and  Production  Planning 

28.  Contractor's  Production  Capability  and  Contractor  Productivity 

29.  Computer  Resources 

30.  Data  Management 
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31.      Metric  Units  of  Measurement 


I") 


Electromagnetic  Spectrum  and  Other  Spectrum  Allocation 

33.  Energy  Eniciency 

34.  Environmental  Impact 

35.  Post  Production  Support 

36.  Administrative  and  Business  Applications  for  Automated  Information  Systems 

37.  Cost  Visibility  and  Control 

38.  Industrial  Modernization  Improvement 

39.  Evolutionan.'  Development  and  Acquisition  of  Command  and  Control  System 
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APPENDIX  E 
ONASINST  5000.29  ACQUISITION  STRATEGY 

1.  Needs,  Constraints,  Thresholds,  and  Program  Structure 

a.  Statement  of  Need 

b.  Program  Constraints  and  or  Thresholds 

c.  Resources  and  Funding 

d.  Program  Structure 

2.  Risk  Analysis 

3.  Strategy  to  Achieve  Objectives  and  Implementation 

a.  Objectives  and  Goals  for  the  Acquisition  Efibrt 

b.  Considerations  and  Rationale  for  Program  Schedule 

c.  Planning  and  Control  of  Critical  Program  Activities 

d.  Acquisition  Alternatives 

e.  The  Plan  for  Selecting  among  Alternatives  and  the  Timing  of  Key  Selection 

Decisions 

f      The  Interdependence  of  the  Acquisition  EfTort  with  Other  Programs 

g.      Risk  Vlanagement  Plan 

h.     The  Approach  for  Desien,  Hardware  Data  Development,  and  Preplanned 
Product  Improvement 

i.  Plans  for  Achieving  Reliability  in  Design  and  Manufacturing 

j.  Standardization  Considerations 

k.  Design-to-Cost  and  Atfordability  Considerations 

1.  Integrated  Logistics  Support  Approach 

m.  Use  of  Organizational  Assets 

n.  Mobilization  Capability 

0.  A  Financial  Strategy 

p.     Plans  for  and   Funding   Required  to  Acquire  Adequate  Subsystems  and 
System  Test  Hardware 

q.     The  Business  Management  Approach 

r.      An  Audit  Trail  of  Key  Acquisition  Decisions 
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APPENDIX  F 
DAR  PROCUREMENT  STRATEGY 

1.  Description  of  the  Program.  Item  or  System 

2.  Prosram  Fundinc  (R&D  and  Production),  includinc  a  Summary'  of  Monies  in 
theT^DP  Budgcl  Submissions 

3.  Delivery  Requirements.  Both  R&D  and  Production  Contracts 

4.  Applicabilitv    of   a    Decision    Coordinatins    Paper.    Program    Memorandum, 
Defense  Sys'tem  Acquisition  Review  CounciH  or  Internal  Service  Review 

5.  Background  and  Procurement  History 

6.  Discussion  of  Program  Risk.  Including  Technical.  Cost,  and  Schedule  Risk 

7.  Integrated  Logistics  Support  Planning  Concept 

8.  Application  of  Design-to-Cost 

9.  Application  oi"  Life  Cycle  Cost 

10.  Reliability  and  Maintainability  Objective,  including  Warranties 

11.  Test  and  Evaluation  Approach 

12.  Management  Information  Program  Control  Requirements 

13.  .Approval  for  Operational  Use 

14.  Government-Furnished  Material  Facilities  Component  Breakout 

15.  Application  of  Should  Cost 

16.  Milestone  Chart  .Attachment  Depicting  the  Objectives  of  the  Acqtiisition 

17.  Milestones  for  Updating  the  Procurement  Plan 

18.  Identification  of  Participants  in  the  Procurement  Plan  Preparation 

19.  Procurement  Approach  for  Each  Proposed  Contract 
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APPENDIX  G 
FAR  ACQUISITION  STRATEGY  PLAN 

1.  Acquisition  Background  and  Objectives 

a.  Statement  of  Need 

b.  Applicable  Conditions 

(1)  Requirements  for  Compatability  with  Existing  or  Future  Svstems  or 
Programs 

(2)  Any  Kown  Cost,  Schedule,  Capability,  or  Performance  Constraints 

c.  Cost 

(1)  Life-Cycle  Cost 

(2)  Design-to-Cost 

(3)  Application  of  Should  Cost 

d.  Capability  or  Performance 

e.  Deliven.'  or  Performance-Period  Requirements 
f      Trade-offs 

g.     Risks 

2.  Plan  of  Action 

a.  Sources 

b.  Competition 

c.  Source-Selection  Procedures 

d.  Contracting  Considerations 

e.  Authority  for  Contracting  by  Negotiation 
f  Budgeting  and  Funding 

g.  Product  Descriptions 

h.  Priorities,  Allocations,  and  Allotments 

i.  Contractor  Versus  Government  Performance 

j.  Management  Information  Requirements 

k.  Vlake  or  Buy 

1.  Test  and  Evaluation 

m.  Logistics  Considerations 

(1)  Assumptions  Determining  Contractor  or  Agency  Support 

(2)  Reliability,    Vlaintainabilitv,   and   Qualitv   Assurance    Requirements, 
Including' any  Planned  Use's  of  Warrantie's 
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(3)  Requirements  For  Contractor  Data  (Includins  Purchase  Data)  and 
Data  Rights,  Their  Estimated  Costs,  and  the  Cse  to  be  Made  of  the 
Data 

n.  Government-Furnished  Property 

0.  Government- Furnished  Information 

p.  Environmental  Considerations 

q.  Security  Considerations 

r.  Other  Considerations 

s.  Milestones  for  the  Acquisition  Cycle 

t.  Identification  of  Participants  in  Acquisition  Plan  Preparation 
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APPENDIX  H 
A-109  ACQUISITION  STRATEGY 

1.  Contracting  Process 

2.  Scheduling  of  Essential  Elements 

3.  Demonstration  Test  and  Evaluation  Criteria 

4.  Content  of  Solicitations  for  Proposals 

5.  Decisions  on  Whom  to  Solicit 

6.  Methods  for  Obtaining  and  Sustaining  Competitors 

7.  Guidelines  for  Evaluation  and  Acceptance  or  Rejection  of  Proposals 
S.  Goals  for  Design-to-Cost 

9.  Methods  for  Projecting  Life  Cycle  Costs 

10.  Use  of  Data  Rights 

11.  Use  of  Warranties 

12.  Methods  for  Analyzing  and  Evaluating  Contractor  and  Government  Risks 

13.  Need  for  Developing  Contractor  Incentives 

14.  Selection  of  the  Tvpe  of  Contract  Best  Suited  for  Each  Stage  in  the  Acquisition 
Process 

15.  Administration  of  Contracts 
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APPENDIX  I 
NARSUP  ACQUISITION  STRATEGY  PLAN 

A.  Acquisition  Background  and  Objectives 

1.  Statement  of  Need 

2.  Applicable  Conditions 

(a)  Requirements  for  Compatabilitv  with  Existing  or  Future  Svstems  or 
Programs 

(b)  Any  Kown  Cost,  Schedule,  Capability,  or  Performance  Constraints 

3.  Cost 

(a)  Life-Cycle  Cost 

(b)  Design-to-Cost 

(c)  Application  of  Should  Cost 

4.  Capability  or  Performance 

5.  Deliver}"  or  Performance-Period  Requirements 

6.  Trade-offs 

7.  Risks 

8.  Applicabilitv  of  a  DCP,  Program  Memorandum,  DSARC,  and,  or  Internal 
Service  Review 

9.  Approval  for  Operational  Use 

10.  Milestone  Chart  Depicting  the  Objectives  of  the  Acquisition 

11.  Milestones  for  Updating  the  Acquisition  Plan 

B.  Plan  of  Action 
I.     Sources 

Competition 
Source-Selection  Procedures 

4.  Contracting  Considerations  Contracting  Type 

5.  Budgeting  and  Funding 

6.  Product  Descriptions 

7.  Priorities,  Allocations,  and  Allotments 

8.  Contractor  Versus  Government  Performance 

9.  Management  Information  Requirements 

10.  Make  or  Buy 

11.  Test  and  Evaluation 
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2_ 
J. 


12.  Logistics  Considerations 

(a)  Assumptions  Determining  Contractor  or  Agency  Support 

(b)  Reliability.  Maintainability,  and  Quality  Assurance  Requirements. 
Including  any  Planned  Use's  ol  Warranties 

(c)  Requirements  for  Contractor  Data  ( Including  Purchase  Data)  and 
Data  Riehts,  Their  Estimated  Costs,  and  the  Cse  to  be  Made  of  the 
Data 

(d)  Standardization  Concepts 

13.  Government-Furnished  Property 

14.  Government-Furnished  Information 

15.  Environmental  Considerations 

16.  Security  Considerations 

17.  Other  Considerations 

18.  Milestones  for  the  Acquisition  Cycle 

19.  Identification  of  Participants  in  Acquisition  Plan  Preparation 

20.  Acquisition  Approach  for  Each  Proposed  Contract 

(a)  Item  Description 

(b)  Estimated  Cost 

(c)  Sources,  Proposed  Sources  and  Basis  for  Selection 

(d)  Source  Selection  Procedures 

(e)  Contracting  Considerations/Contract  Type 
(0  Competition 

(g)  Repurchase  Data 

(h)  Incentives 

(i)  Alternative  Acquisition  Approaches  Considered 

(j)  Vlilestones  for  the  Acquisition/Contract  Cycle 

(k)  Other  Considerations 

(1)  Contract  Award  Requirement 

(m)  RDT&E  Information 
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